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

How to handle local state changes #38

Open
brumm opened this issue Nov 13, 2019 · 1 comment
Open

How to handle local state changes #38

brumm opened this issue Nov 13, 2019 · 1 comment

Comments

@brumm
Copy link

brumm commented Nov 13, 2019

Hey,

I'm intrigued by this library, but I'm not yet clear on whether it would fit our use case. Currently, coordinating all the different fetches and their state is a big headache, which ReSift seems to have a good solution for.

I'm curious however how I'd incorporate stuff like optimistic updates (immediately setting state, then potentially rolling back if api says nay) and local state changes which do not involve communicating with a server in general.

@ricokahler
Copy link
Contributor

Hey @brumm 👋,

I'm glad you're interested! At the current state, ReSift is unopinionated when it comes to optimistic updates. We have a solution for when you want to keep state consistent in regards to a PUT vs a GET request but nothing currently for keeping a local expected mutation in sync. I'd be open to exploring adding features though.

However, with ReSift today, you can achieve the same result by using react state and a few effects:

Take a look at this example:

import React, { useEffect } from 'react';
import { useDispatch, useData, useStatus, isLoading } from 'resift';
// these are "fetches" which are tokens the represent your request
// see https://resift.org/docs/main-concepts/how-to-define-a-fetch
const getResource = /* ... */;
const updateResource = /* ... */;

function Resource() {
  const dispatch = useDispatch();
  // pull the latest synced resource from the server using `useData`
  const resourceSyncedFromServer = useData(getResource);
  // pull the status and create an `isSyncing` variable
  const status = useStatus(getResource);
  const isSyncing = isLoading(status);

  // create some local state
  const [resource, setResource] = useState(resourceSyncedFromServer);

  // create an effect that will sync the server state to the local state
  useEffect(() => {
    if (isSyncing) return; // early return if something is still in the works

    if (resourceSyncedFromServer) {
      setResource(resourceSyncedFromServer);
    }
  }, [resourceSyncedFromServer, isSyncing]);

  // create an effect that will sync the local state to the server state
  useEffect(() => {
    // prevent infinite loops
    if (resource !== resourceSyncedFromServer) {
      dispatch(updateResource(resource));
    }
  }, [resource]);

  // this is an example of a handler.
  // the idea is you can always just set the local state and it will automatically update on the server via the effects
  const handleChange = e => {
    const nextResource = getResourceFromEvent(e);
    setResource(nextResource);
  }

  return (
    <>{/* ... */}</>
  );
}

It uses two effects to do the syncing of local state to server state. If you're interested in this pattern, I can try to flesh it out a bit more and we can have more formal discussions if we should move it internally to ReSift. Since ReSift is hooks based, it wouldn't be very difficult to create a custom hook that implements this pattern as well.

If you need the state to be more global, you can also write some custom hooks that use React context to provide state to any component in the tree without having to pass props.


Let me know what you think of the above approach!

However, if you always want to have this pattern of updating state locally, I would suggest checking out some other data fetching libs that revolve around this. Both zeit's SWR and tanner's react-query have built in "stale-while-revalidate" (SWR) approaches that might suit your needs better.

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

No branches or pull requests

2 participants