Don't require local resources and getters to have globally unique names #1051
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR continues the work of #1050 in trying to simplify
requestData
. #1050 removed Pinia, making it such that different local resources are more independent of one another. Under Pinia, two local resources with the same name (created at different times) would share the same Pinia store. We've now removed these shared Pinia stores, but there is still a constraint on local resources: it's not possible for two local resources created at the same time to have the same name, even if they are created in different components. In other words, resource names must be globally unique, even for local resources.My goal in this PR is to make local resources and getters as similar to
provide
/inject
as possible. That's already the mechanism that they're using under the hood.provide
/inject
is happy to shadow an existing value with the same name. NowrequestData
will be fine if a local resource or getter shadows one from an ancestor component. It's not like we have a pressing need for shadowing, but by allowing it, we can simplifyrequestData
. For example, we can consolidate all cleanup inonUnmounted()
rather than usingonUnmounted()
for some things andonBeforeUnmount()
for other things. I also think that allowing shadowing clarifies the mental model around local resources: local resources should be fully independent of one another.Before submitting this PR, please make sure you have:
npm run test
andnpm run lint
and confirmed all checks still pass OR confirm CircleCI build passes