This really works and is cool

[MiroslavPetrik]

Hello

It seems this just solved a problem for me. I have a use case, where I have list of form fields. This list is dynamic, that you can add, remove or move the items inside of it. It is the splitAtom from jotai/utils.

For all the form fields, I have a name atom, which will be used as the name attribute in the <input /> element.
I wanted this name, to observe its "list item" which will have name of the listName + index in the splitAtom.

That way I get scoped names. But this is chicked-egg problem, since I construct the atoms bottom-up, meaning when the form field is built, it does not know about its context - the form item, so it cant get(listItem) name, since the form item does not yet exist.

But once the list item is created, it knows about its children, so I've decided to manage them with effects, and "override" their inner nameAtom with one which reads both the listItem name & form field name. https://github.com/form-atoms/field/blob/00d597b83cd944b505f89a57d829a0b414b11883/src/atoms/list-atom/listItemForm.ts#L154

I'm happy with this, the api seems straightforward and easy to understand as with the rest of jotai, also the readme docs answered my questions!

But since the library has major version 0, I have some doubts on how experimental all this is. So I have few questions:

• Does the mount happen also on SSR first render?
  My use case does not cause hydration mismatch, which I'm a bit surprised. So far I've tested it with one form (in next.js 14), which previously has thrown hydration mismatch for me (for different feature outside of jotai-effect). So I was expecting to see hydration mismatch again with the form field names to be in the "pre atomEffect" mode.

Or both server & client initial render happens without the mounted effect?
That way perhaps I will reconsider using it, as I would like to have the names set properly even initially.
Or I will need to enhance the solution, so first the names will be computed in a different way, as there is no need to keep track of the dynamic list changes like item add, remove or move actions....

• How experimental this is, or how stable this is?
  Is there some vision on when a version 1.0.0 could be achieved? Are there some unstable hacks behind this?

• Testing best practices?
  I got some warnings from my test env on how the TestComponent got updated after the effect, so likely for each component using some atomEffect, this case must be handled.

Thank you so far for this work!

[dmaskasky]

Its nice to hear atomEffect solved your problem and you're happy with the solution. 😄

Answering your questions...

1. Does the mount happen also on SSR first render?

I don't think so. atomEffect internally depends on Jotai's atom.onMount firing and in SSR my understanding is that atoms are never mounted. I do not expect the atomEffect to ever fire in an SSR environment.

2. Or both server & client initial render happens without the mounted effect?

You can achieve this by conditionally mounting the atomEffect when your atom mounts.

const isMountedAtom = atom(false)
isMountedAtom.onMount((setSelf) => setSelf(true)) // changes isMounted to true onMount
const derivedAtom = atom((get) => {
  if(isMountedAtom) {
    get(effectAtom) // conditionally calls atomEffect
  }
  return get(valueAtom)
})

3. How experimental this is, or how stable this is? Is there some vision on when a version 1.0.0 could be achieved? Are there some unstable hacks behind this?

Its a young project but we are targeting version 1.0.0 after we have collected enough feedback from developers on its api. In my opinion, the api has stabilized and I don't see any issues with the library in its current form. My plan is to let jotai-effect bake for another month or two and then promote it to 1.0.0.

Longer term, if Jotai adds support for RSC, I'd like to solve the SSR / RSC question. This likely wouldn't be a breaking change but it would be a significant enough update to warrant a major version bump. Other than that, there's nothing else on the horizon at the moment.

4. Testing best practices? I got some warnings from my test env on how the TestComponent got updated after the effect, so likely for each component using some atomEffect, this case must be handled.

Could you please create a simple codesandbox / stackblitz example? I can take a closer look.