Replies: 1 comment
-
You have a couple options you can try. atomFamilyconst filtersAtomFamily = atomFamily(() => atom<Record<string, boolean>>({}))
const table1Symbol = Symbol('table 1')
export function Table1() {
const [filters] = useAtom(filtersAtomFamily(table1Symbol))
return (
<Provider>
...
</Provider>
)
} ScopeProviderimport { ScopeProvider } from 'jotai-scope'
const filtersAtom = atom<Record<string, boolean>>({})
function Table1() {
const id = useId()
const [filters] = useAtom(filtersAtom)
return (
<>
...
</>
)
}
export function ScopedTable() {
return (
<ScopeProvider atoms={[filtersAtom]}>
<Table1 />
</ScopeProvider>
)
}
...
function ParentComponent() {
return (
<>
<ScopedTable />
<ScopedTable />
</>
)
} creating an atom in render functionexport function Table1() {
const filtersAtom = useMemo(() => atom<Record<string, boolean>>({}), [])
const [filters] = useAtom(filtersAtom)
return (
<Provider>
...
</Provider>
)
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm aware of using
initialValues
on aProvider
for purposes like testing, SSR, initializing on render (props), etc. but I'm curious within the context that I have a static use-case that doesn't rely on render initialization.I guess in other words what I'm asking is if there some way to create an atom config and then define the
initialState
after the config is created?For the sake of a basic example I have a basic FilterDialog that effectively owns the
filtersAtom
as a reusable component. Let's say this component will be reused across several tables as the standard way to configure the filtered selection of certain categories/groups of items to show in a table. The catch comes that with each table there is some default filters I want to enable.Here's a pseudocode example to understand:
FilterDialog.tsx
Table1.tsx
const defaultFilters = { isX: true, isZ: true }
As the example shows there'll be a Table2, 3, etc. Not all will be the same but the idea is the dialog "owns" the state as a reusable subject and does the actual management. The parent table then "subscribes" to see what filters are currently used and does whatever it needs to do.
Again, up until now this seems like an ideal solution. The complication starts when say in Table1 I want the default filters to be
{ isX: true, isY: true }
and on Table2 I want{ isZ: true }
. I'm aware of theinitialValues
withuseHydrateAtoms
but I guess the catch here is the default values are statically defined and so they can be set in React, but don't need to be part of render initialization.I'm mostly curious if there's some interesting pattern for this? I believe the
initialState
is an intrinsic part of the atom "config" correct, so it would be impossible to statically define aninitialState
after?It would seem the approach would be to go about this the entirely opposite way, define the atom above the
Table
component and pass the atom to theFilterDialog
as a prop? Then everything could mostly be static, but it would require prop-drilling or creating a Context the atom config would go in. Between passing an atom config as props or usinginitialValues
/useHydrateAtom
is there a "better" approach from the perspective of the library for such a "static" use case? Is there some other creative approach I have missed? Is there an atoms-in-atoms approach that could help with this?Beta Was this translation helpful? Give feedback.
All reactions