merisbahti / klyva Goto Github PK

Create docs/*.md detailing:

• Comparison to similar libraries (recoil, mobx, jotai)
• Async (or why doesn't klyva have async atoms - atoms are cheap! you should just use useQuery or useSwr, or .server-components for data fetching!)
• Explain why focusAtom and useAtomSlice, with prop drilling, enable you to build more testable apps.

In an older version of https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering we had klyva included. At that time, klyva was passing all tests except this one:

check with useTransition
  ✕ check 7: proper branching with transition (6127 ms)

What is this test 7 checking? Is this something that is hard to fix in klyva? If it needs a de-optimisation, could it be as an optional extra or a plugin or monkeypatch under a contrib/ folder, so that klyva could be the first to pass all the known tests for concurrent mode? 🎉

☝️ asking for a friend :) cc @kkogovsek

Make a 5 minute tutorial with associated starting code sandbox.

High level script:
What is klyva (simplified state management, basically just useState)
Start by building TodoItem component
Make that TodoItem take an atom as a prop (global state that feels local)
Expand and build TodoList

Some things that came up when trying out Klyva:

• make optics part of the Klyva tagline. it's the thing that really sets this lib apart from all others. good to communicate that from the start.

• considering optics is such a big thing in this library, I think it would be great to give some practical examples.

• start examples with import statement, e.g.

import {atom} from 'klyva'

const countAtom = atom(5)

• I know it's written in the docs but I still didn't parse it completely when I read it: it's if you want your component to update when an atom changes, you gotta use the useAtom or useSelector hook in that component.

the source code in "react-utils.ts" is importing and using both react and react-dom packages directly, but these packages are not included in the dependency field in your package.json (they are however located in devDependencies).

you could add them under peerDependencies field as ^16.8.3 to allow the end user to supply their own react/react-dom version from their project

I would like to try doing something like this,

const sumAtom = atom(async get => {
  get(atomOne)
  return await fetch("/api");
})

To capture the interest of developers, it would be beneficial if:

1. Understanding is easy. Ideally the "above the fold" view of the repo (and npm / ... flutter pub page) is enough to be able to make use of the library.
2. Dipping your toes is easy. Ideally an easy to remember import line, and "one line" changes in the actual code to use this library instead of whatever was in use before.
3. Swapping is easy. Ideally some compatibility layer that would make it easy to just replace all usage of, say, React.useState with a klyva-based
4. Switching over is easy - have something like a codemod approach for cleaning up after having started doing the above steps and decided to go all-in.

(We discussed this on Discord, and I plan to update this more a bit later)

As discussed elsewhere, it would be awesome to mention useSelector specifically to help users. cc @kkogovsek

Similar to jotai, we should have support for devtools:

https://github.com/pmndrs/jotai/blob/master/src/devtools/useAtomDevtools.ts

https://github.com/pmndrs/jotai/blob/master/docs/debugging.md

It took the Malmö Meetup (remote) recording where this screenful of code is explained to see why it's useful to sling around atom names as strings.

If we assume jest, and optionally some jest-extension, what developer experience should there be for testing an app built with klyva?

Maybe something like klyva.resetAll() to move klyva state to initial? How would this be done with a redux-based app?

Thanks! Came here from pmndrs/jotai#13 and pmndrs/jotai#44