Refactor and polish scope handling in environments table
The following discussion from !80948 (merged) should be addressed:
-
@pslaughter started a discussion: (+1 comment) suggestion: Instead of building this property name, I think it'd be preferable to decouple the
scope
value from this property name. That way we can do things like easily search forstoppedCount
to find it's references.🤔 We can do a condition here or even create something fancy in the resolver like:
countsByScope: { [SCOPE.AVAILABLE]: available_count, [SCOPE.STOPPED]: stopped_count, },
WDYT @afontaine?
how would you feel about saving this for a follow-up to better decouple scope overall? There's a lot of code that is similar in the main component that could benefit from a shared set of utilities mapping scopes to counts, tabs to scopes, and so on.
-
@pslaughter started a discussion: (+2 comments) issue (non-blocking): Since the query string technically comes from user land, it might be nice for us to robustly support invalid values for
scope=
Not necessarily related to this MR
😄
Implementation Plan
TBD...