Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document customizing getKey and getData fetching #241

Merged
merged 4 commits into from
May 30, 2024

Conversation

DmitryGonchar
Copy link
Contributor

@DmitryGonchar DmitryGonchar commented May 27, 2024

e.g. to pass a different route parameter value to them.

These clarifications are result of a pairing session with @albertogasparin

Copy link

changeset-bot bot commented May 27, 2024

⚠️ No Changeset found

Latest commit: 88a99e8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@@ -17,9 +17,9 @@ export const userProfileResource = createResource({
| Property | type | Description |
| --------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `type` | `string` | Used as a namespace for this resource. Each resource should have a unique type |
| `getKey` | `(routerContext, customContext) => string` | The return value of this function is used to identify this resource within the `type` namespace. The function itself is supplied with `routerContext` and `customContext` so that the composition of keys can use this data if required |
| `getData` | `(routerExtendedContext, customContext) => Promise<any>` | This function is used to load the data for the resource. The function should return a promise and resolve with the resource data object. NOTE: You may not use `getData` and `getDataLoader` on the same resource |
| `getKey` | `(routerContext, customContext) => string` | The return value of this function is used to identify this resource within the `type` namespace. The function itself is supplied with `routerContext` and `customContext` so that the composition of keys can use this data if required. `customContext` comes from the top level Router component, therefore changing it will cause a re-render of almost everything in your React app. You may want to pass a custom `routerContext` instead. How to do this - see the ["Accessing resource state for another route or url"](https://atlassian-labs.github.io/react-resource-router/#/resources/usage?id=accessing-resource-state-for-another-route-or-url) section. The router will fetch and cache data for that route then. |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand this sentence in the context of getKey function.

therefore changing it will cause a re-render of almost everything in your React app

customContext is immutable within getKey function scope, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what Alberto said, can you please clarify with him, and make edits if necessary?

Afaiu, if we put a new prop into customContext, it means that all child components of Router will get re-evaluated. And it was not recommended for that reason. But yes, adding more specific details here'd be helpful, I just don't have them :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the confusion is because describing side effects of changing customContext while we talk about resources is misleading. Maybe something like this is easer to grasp?

The function itself is supplied with routerContext and customContext so that the composition of keys can use this data if required. customContext comes from the top level Router component and therefore is value is equal across resources. routerContext contains the current route and location data, which comes from the current URL or from some manually provided value (see the "Accessing resource state for another route or url" section). The router will fetch and cache data for that route then.

Copy link
Contributor Author

@DmitryGonchar DmitryGonchar May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm. @liamqma is Alberto's version clearer? I've updated the PR.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make senses. Thank you @albertogasparin and @DmitryGonchar

@liamqma liamqma merged commit 55e342e into atlassian-labs:master May 30, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants