docs: read updates #2
Conversation
|
|
||
| ```ts | ||
| // useRead sets up a global subscription for changes & | ||
| // will rerender when items are added/removed but NOT if a doc's values change |
There was a problem hiding this comment.
I get a little confused here.
-
If task name in task-294 changes, it won't be re-rendered
-
if a new task is included in Firestore, then it will re-render
correct?
There was a problem hiding this comment.
In this code if TASK-294 changes the title only the listItem for TASK-294 will be pre-rendered. This is because we use the list parent only gets an array id & path. That doesn't change so no render happens. Each item component also doesn't have any changes so only the component with the new title will pre-render.
There was a problem hiding this comment.
If a new task is add (or the order of the tasks is changed) then the parent will re-render. When it re-renders the key, id and path are the same for all the existing component so they will not re-render. Only the new item will be added and rendered in React.
There was a problem hiding this comment.
This is why the useRead and the useCache are so powerful. We can skip huge amount of React dirty checks and React renders because useRead and useCache can do a shallow equality check to skip React checks. When we only pass props to a component that are primitives then React is do a simple equality check and skip all expensive dirty checks and re-renders.
There was a problem hiding this comment.
@victorodgs is there a better way we can say this?
There was a problem hiding this comment.
Would it be better to say we should only render a list from IDs and then useCache at a lower level for display data like title?
docs/read.md
Outdated
|
|
||
| In Read/Write subscriptions are turned on by default. Anytime useRead is | ||
| called it automatically listens for any document changes both locally and | ||
| global and will rerender when data changes. As of v1, there is not a single |
There was a problem hiding this comment.
Since rendering is not part of this library, I think it is important to distinguish between rendering and updating the data. In this case, I would say that the component that read is then listening to any data changes
There was a problem hiding this comment.
Yes, our library manages data loading and updates. But the reader are all using it inside their React component.
So the doc should be written to who the reader is. In this case it's a UI engineer wanting to know how it will affect their rendering.
For the deep dive docs their purpose is for a library maintainer. So those show go deeper into when the data updates, where the strict vs shallow vs deep equality checks are and how they will impact the callee which is a React component and if it will do a costly dirty check.
| global and will rerender when data changes. As of v1, there is not a single | ||
| fetching; only a fetch and subscribe for global changes. | ||
|
|
||
| You can minimize when rerender are triggered by selecting a |
There was a problem hiding this comment.
Same here, as I see it, what you are minimizing is the amount of data you are listening to.
| global and will rerender when data changes. As of v1, there is not a single | ||
| fetching; only a fetch and subscribe for global changes. | ||
|
|
||
| You can minimize when rerender are triggered by selecting a |
There was a problem hiding this comment.
| You can minimize when rerender are triggered by selecting a | |
| Reducing the data requested will reduce the updates to the hook. This will | |
| have the effect of reducing renders of your React component. Reduce updates | |
| and re-renders with a |
|
|
||
| ```ts | ||
| const archiveTask = createMutate({ | ||
| const archiveAction = createMutate({ | ||
| action: 'ArchiveTask', | ||
|
|
||
| read: (taskId) => ({ taskId: () => taskId }), |
Description
Read documentation updates. Please call out anything that's unclear in the documentation.