Does multiple setState at once guarantee to be happened at once in react hooks? – Javascript

the issue here is using useEffect for user actions

both of your usecases are good (according to docs), but only on paper:

• subscribing to webhookSocket
• fetching clips

but due to how you rely on setstate and rerenders to react to user action and for example fetch data, your flow breaks along the way. this, paired with impure functions makes it even harder to trace whats happening.

separate your events

we can break it down in two events that are user triggered, and two that are triggered either outside of react, or just happen without any action.

❌ no useEffect

• user clicks refresh
• user triggers infiniteScroll.next

✅ useEffect

• new socket message
• initial load

heres what i’d change, to accomplish that:

• for getClips() move the implicit dependency on activePage to an explicit page param. that way you can call it whenever you want with the parameters you need
• run the initial getClips() in a run-once useEffect (we should supply getClips as a dependency for useEffect, and thus wrap it in useCallback to make it stable)
• when appending new clipsDetails, dont use a potentially stale value for clipsDetails in the spread. setClipsDetails((prev) => [...prev, ...value?.clips]); this makes sure it uses the right value.
• when clicking the refresh button: refetch data with the currently active page, and reset the "unseen clips" counter.
• when triggering the next event in the infinite scroll: load the next page and increment activePage.

const Mycomponent = () => {
  const [clipcount, setClipcount] = useState(0);
  const [clipsDetails, setClipsDetails] = useState([]);
  const [activePage, setActivePage] = useState(1);
  const [socketClipCount, setSocketClipCount] = useState(0);

  useEffect(() => {
    // i'm 99% sure you dont need the webhookSocket instance inside the component scope. unless it dependes on some component state (like a room-id) you should move it outside of the component definition. that way its stable and not required as dependency.
    webhookSocket.on(`livecut${id}`, (data) => {
      setSocketClipCount((socketClipCount) => socketClipCount + 1);
    });
    return () => {
      // unsubscribe from webhookSocket
    };
  }, []);

  const getClips = useCallback(async (page) => {
    const { value } = await getAllClips({
      limit: clipLimit,
      pageNo: page,
      sort: { _id: -1 }
    });
    if (value?.success) {
      setClipcount(value.totalLength);
      setClipsDetails((prev) => [...prev, ...value?.clips]); // use the current value of clipsDetails in the spread
    }
  }, []);

  useEffect(() => {
    getClips();
  }, [getClips]);

  return (
    <div className="custom-generated-clips styled-scroll">
      {socketClipCount > 0 && ( // dont use non booleans with `&&` in jsx, as this will render the 0 as text
        <button
          onClick={() => {
            getClips({ page: activePage });
            setSocketClipCount(0);
          }}
        >
          Refresh ({socketClipCount})
        </button>
      )}
      <InfiniteScroll
        dataLength={clipsDetails?.length}
        hasMore={clipsDetails?.length < clipcount} // `? true : false` not needed as this already returns boolean
        next={() => {
          setActivePage(activePage + 1);
          getClips({ page: activePage + 1 });
        }}
        loader={
          <div className="InfinitScrollLoadingBottom">
            <div className="InfinitScrollLoadingBottomText">Loading...</div>
          </div>
        }
        endMessage={
          <div className="InfinitScrollEndBottom">
            <div className="InfinitScrollEndBottomText">
              {clipsDetails?.length > 4 ? "You've reached End!" : ""}
            </div>
          </div>
        }
        // pullDownToRefreshThreshold={limit}
        scrollableTarget="scrollableDiv"
      >
        {myData}
      </InfiniteScroll>
    </div>
  );
};

export default Mycomponent;

i’ve added a few more smaller things as comments. i hope this helps.
i’d highly recommend reading this article in the new react docs, as this helps you prevent error-prone uses of useEffect