A virtualized table implementation with per cell stale time

[marbemac]

Hi @bowheart - now that the holidays are over, I finally had a chance to dig into Zedux with a more complex example. This is that virtualized data table / grid that I mentioned earlier.

I had some fun putting it together today, BUT I'm not sure that I did things the "zedux" way across the board. It's easy to run locally, and I included a quick gif in the readme to give an idea of what it does. I also added some comments tagged with @QUESTION with notes on bits I was particularly unsure about as I put it together.

No rush at all, but if you have a little time in the next couple of weeks and are able to take a look at the implementation to offer some pointers I'd really appreciate it. Also, if a more advanced example like this is something that could be helpful to others I could clean it up (and/or simplify it) for broader consumption.

Thanks in advance!

https://github.com/marbemac/zedux-grid-example

[bowheart]

@marbemac amazing! I'll try to find some time to look over it in the next few days.

[marbemac]

Hmm ok a couple of follow-up questions.

I've got a populate function using injectCallback here -> https://github.com/marbemac/zedux-grid-example/blob/main/app/atoms/records.ts#L165

1. I'm passing store into the deps array, is that unnecessary since if I remember correctly injectStore returns a stable ref anyways?
2. This populate function is exported in the atom's api. Is this a problem, since the records value from injectAtomInstance is passed into the populate deps? Is it not possible to export functions that use dynamic values (via deps array)?

So far I think my difficulties with Zedux can be broadly broken down into two categories:

1. There sometimes seem to be multiple ways to accomplish the same thing, which causes me to be unsure about when to use what and if there are tradeoffs. An example of this would be atom getters vs injectors (e.g. getInstance from injectAtomGetters vs injectAtomInstance).
2. The "rules of zedux" - similar to react's "rules of hooks" except it seems that zedux has even more of these tricky behaviors (like remembering that setExports only actually does something on the atom's first run). A little worried about myself (or other devs on the team) introducing subtle bugs because they don't know about or remember these rules all the time.

Enjoying Zedux and I like a lot of the ideas in it! Just thought I'd share some initial feedback as a new user.

[david-trumid]

Love the feedback!, so in this case

    const populate = injectCallback(
      (force = false) => {
        const { value, version, populatedAt } = store.getState();

        /**
         * Consider the value stale if it was populated more than X seconds ago, and refetch it.
         */
        const isStale =
          populatedAt && Date.now() - STALE_DATA_THRESHOLD > populatedAt;

        if (!force && value !== undefined && !isStale) {
          return;
        }

        records.exports.populateAttribute(recordId, columnId);
      },
      [store, records]
    );

both store (a Store) and records (an atom instance) are stable references and neither are technically needed in this depList.

and since it is only using stable references you dont need the injectCallback and it is perfectly safe to export it. Basically as long as your exports are accessing stable references you are good. You are good to use the dynamic values because you are accessing them from the export itself which is fine.

On the multiple ways..

Totally understood, think we will be simplifying these in future versions (@bowheart can confirm for sure) I could go into background of how it evolved if you would like but a quick summary is those things are basically the same thing under the covers just useful in different scenarios. For instance if all you need is to inject and atom instance then all you need is injectAtomInstance.. however if you need to inject values, instances, selectors or multiple of each.. there is a helper to expose all of them. Not to confuse you more but.. if you are deriving an atom from other atoms (like your recordAttributeAtom is based off recordsAtom) then you might enjoy using ion's for those, those give you the atom getters as the first parameter and resemble more like recoil. For instance..

export const recordAttributeAtom = ion(
 { getInstance },
  "record-attribute",
  ({
    objectId,
    recordId,
    columnId,
  }: {
    objectId: string;
    recordId: string;
    columnId: string;
  }) => {
    const store = injectStore({
      value: undefined as string | undefined,
      version: 0, // Tracking this just to show in the UI when a record attribute is re-fetched, for example purposes
      populatedAt: null as number | null,
    });

    const records = getInstance(recordsAtom, [{ objectId }]);

It makes more sense as you get more and more complicated and need multiple instances/values/selectors.

[marbemac]

and since it is only using stable references you dont need the injectCallback and it is perfectly safe to export it

Cool that's what I figured. Atm is it not possible to expose functions with dynamic deps via the api exports?

Totally understood, think we will be simplifying these in future versions

❤️

Not to confuse you more but.. if you are deriving an atom from other atoms (like your recordAttributeAtom is based off recordsAtom) then you might enjoy using ion's for those

Is deriving atoms from other atoms a common use case, or should I try to avoid that somehow? Asking because I'm doing this all over the place ha.

Hmm, hadn't even considered ions. Haven't looked much into it, on initial quick read of the docs I categorized it in my head as "ok this is for when I need more complex computed data memoized" - is that indeed the main use case? In this example does it provide any benefit beyond exposing the atom getter functions?

Thanks for your help!

[david-trumid]

No Ion is just some syntactic sugar :D

We have thousands of atoms and we have yet to need an export to be dynamic (since the consumer calls it and it will then have access to anything in the atom definition which can then be stable as well) so I think we haven't actually needed that use case. Usually if the consumer wants to call a dynamic function they would be subscribing to the atom store itself and when it calls the export the export can access through stable references

[bowheart]

is it not possible to expose functions with dynamic deps via the api exports?

Atoms support this via state. If the function ref needs to change, then it's state. Consumers need to be notified of the change. Stores handle all that. There's nothing wrong with putting functions in state (as long as you're not trying to serialize them).

Exports are different. Treat them like JS module exports - when you export function MyExport() {}, that function reference never changes.

We do have multiple ways to do things, and yeah there's a history behind all of it. We can discuss cleaning some of those up. In fact, I just opened #143 to discuss utils packages. Some of Zedux's core APIs should have probably been utils in there.

Is deriving atoms from other atoms a common use case

This is what atoms are for. It's why atomic libraries scale better than singletons like Redux and is probably the main reason why Zedux exists.

[bowheart]

Updating here for completeness: I did a deep dive on this project, answering all questions and migrating the code to use Zedux v2. Amazing project @marbemac thanks for sharing.

See my fork PR: marbemac/zedux-grid-example#1