jason89521 / daxus Goto Github PK

Allow developer to set which accessors are stale. Like React Query's queryClient.invalidateQueries.

Since revalidate and fetchNext is bound to the accessor, it is better if useAccessor can return the accessor such that developers can directly return the result of the useAccessor.

Like Redux or React Query, we should also build a devtool to make debugging easier. This should be done after the api stable. However, I haven't built an extension, I should research it.

Currently the auto accessor only notifies the listener inside it instead of notifying the whole model. If developers mutate the model, it would not cause a rerender.

We have two way to fix it:

1. notify the corresponding accessor when developers mutate the model
2. remove the self listeners, the accessor directly notify the model's listeners

I prefer the first approach.

Consider the following situation in swr:

function Post({revalidateOnFocus}) {
 	const {data} = useSWR('post1', fetcher, { revalidateOnFocus});
	return <div>{data.title}</div>
}

function App() {
	return <div>
		<Post revalidateOnFocus={true} />
		<Post revalidateOnFocus={true} />
	</div>
}

revalidateOnFocus will be enabled because the first useSWR receive true. I think this is more friendly for the user.

My current idea is to hydrate based on different accessors. The API might look like this:

const postAdapter = createPaginationAdapter({});
const postModel = createModel(initialModel);
const getPostById = postModel.defineAccessor('normal', {
    // configuration
});

function Page({ post }) {
    useHydrate(getPostById(post.id), () => {
        postModel.mutate(model => {
            postAdapter.upsertOne(model, post)
        })
    })
}

The useHydrate function will record the provided accessor and execute the function if the current accessor hasn't been recorded yet. When the accessor changes, it removes the previously recorded one and records the new one. In the example above, this ensures that when post changes, we can update the model in real-time.

However, this approach has a drawback. Developers need to place useHydrate at the top level of the component tree to manage accessors centrally and avoid duplicate accessors being passed. Additionally, attention needs to be paid to which models need to be hydrated on which pages to prevent data from being missed.

In swr, if the key is null, then the request will not be emitted. We should also implement this.

Like this example of react query.

Currently the accessor will notify the whole model's listener. This may cause performance issue if the lazy model define many accessors. Since the accessors defined by the lazy model don't have dependencies, we don't need to notify the whole model after the fetching is done.

Currently model.getState only accept an accessor instance to get the state, it is better if we can allow developers to get all the data corresponding to the accessor creator.

This issue should be handled after I finish the streaming rendering stuff.

• packages
  • daxus
  • daxus-eslint-plugin
  • daxus-devtool
• website

Just like React Query's queryClient.invalidateQueries.

Currently the accessor.revalidate just return void, I think it should return the result which is about whether the revalidate is successful or not.

setIsStale allow developers to determine whether the data is stale or not. getIsStale will be used in useAccessor in order to check whether the accessor should invoke revalidate.

The checkHasStale function from the options should be renamed to another one since it is not related to whether the data is stale or not.

In most case, developers don't need to specify transform or getId when creating pagination adapter. If we provide a generic pagination adapter, it may reduce the code that developers need to write.

Since we would delete the idle accessor, if an infinite accessor is deleted, the pages number it has fetched will be delete also. If developers call accessor.revalidate(), the accessor would only fetch the first page.

We need to find a way to record the pages number.

Should provide an option to allow developer to determine whether it should refetch.

Like React query's useMutation. This feature is not the most urgent and will likely be implemented after the accessor API stabilizes.

It may be useful if some fetching need to read the model's state. Instead of requiring developers to call model.getState(), we can provide it directly in fetchData.

The model created by this function doesn't require developers to specify how to sync the state. It automatically handles it so that developers can use this package just like they use React Query.

To be honest, I'm not very satisfied with the current name, but I can't think of a better one either. If anyone has better suggestions, please feel free to provide them to me.

• List the difference of this project with Redux and SWR
  • Also, write the advantage and disadvantage of these two
• Complete the api documentation
• Write more details about the usage of this project

To prevent too many unused accessor from being stored in memory, we need to delete the accessor if it is idle. An idle accessor means that it is not mounted by any hook and it is not used after a certain interval.

Currently it only return the data or null. It should also return error when fetching fails. It returns null only when the fetching is interrupted by the other fetching.

Since the core of RSM is the adapter, I should add more function to it.

getByXXX

This type of functions should throw error when the corresponding data is not existed.

tryGetByXXX

This type of functions we try to get the corresponding data from the model. If the data is not existed, then it would return undefined

More function about mutating pagination

• prependPagination
• appendPagination
• replacePagination
• removeFromPagination
• and so on...

Currently it use spread syntax to merge the entity. It may be useful if we can let developers determine the merge method.

Developer may need to watch a model if some value changes but they don't want to trigger a revalidation. Add useModel for this use case.

There are two case of the race condition.

• The response returned from request is after the user mutating the model.
• Suppose useInfiniteFetch fetch a post list with id from 1 to 10, and useFetch fetch the post with id 1 later. But the response from useFetch may be in front of the response from useInfiniteFetch. In this case, we will update the model with expired response.

If we re-focus on the window by clicking a button which would fetch next page, then it will trigger the revalidation first instead of triggering fetchNextPage. This should be consider as a bug.

This operation might be useful if developer want to sort the pagination.

Currently fetching next page would not interrupt the ongoing revalidation. This situation would waste user's network.

We need to change the first argument to accept undefined. We can change this hook to accept only one argument also.

It may be convenient if we put the data generic first such that developers don't need to specify void first if the accessor creator doesn't need a argument.

This feature will make this hook more convenient.

getState seems less confusing

The error retry would be invoked immediately if the fetching failed. We should add an interval instead of invoking refetching immediately.

Developers may need to specify some variables for how to update the state. For example, a refresh flag means that the whole pagination need to be refresh. However, refresh is not useful for api fetching. It is useful if we provide a meta to achieve this goal.

The error should be null if no error exist or refetching is success.

Which function need a rule:

• useHydrate: should use the serverStateKey when using model.mutate
• useAccessor: the props or state in getSnapshot function should also appear in the accessor creator
• useModel: the getSnapshot function should be memoized by useCallback

Like React Query, developers can specify how long the accessor will become stale.