[Question] Best practices for large objects?
See original GitHub issueHi all,
So far we are loving jotai
. Amazing work ❤️.
I’d like to start a conversation around best practices for larger objects. Let’s say our back-end gives us a fairly large object which would be mutable at different levels of the object.
const cars = [
{
make: 'Audi',
model: 'RS6',
price: {
value: 999.50,
currency: 'USD'
},
parts: [
{
type: 'engine',
power: 'lot-of hp',
price: { ... },
factoryLocations: [
{ country: 'China', stock: 150 },
{ country: 'Germany', stock: 0 },
]
}, // ... n more
]
},
// ... n more
]
Now our React component tree has <Car />
with a list of <Parts />
, which has a list of <Factory />
s.
What would be the recommended way to go about
- Adding / removing parts
- Adding / updating factory locations
- Updating price
Using jotai
? I am personally very familiar with MobX, where this would be one large observable object (or class instance). However, I am not sure how to look at this in atoms.
Would each car be an atom, with parts turned into atoms and factory locations into atoms? Any other approaches?
I’d love to hear thoughts on this! 😊
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:15 (8 by maintainers)
Top Results From Across the Web
Java passing large objects best practices - Stack Overflow
As I try to split up these large methods, I find myself constantly needing to pass the large case object by reference to...
Read more >Proper practice on handling a large number of objects in ...
My question is, what if I had 1000 students, each with a FName, SName, Address etc. Would I continue on and create 1000...
Read more >Ranking Questions: Dos and Don'ts in 2021 - Qualtrics
Don't create long lists of items for people to rank. Researchers often want to ask respondents to rank huge lists to see what...
Read more >In-depth Interview Questions on Salesforce Objects and ...
You can create only 100 big objects per org. The limits for big object fields are similar to the limits on custom objects,...
Read more >To BLOB or Not To BLOB: Large Object Storage in a Database ...
As expected from the common wisdom, objects smaller than 256K are best stored in a database while objects larger than 1M are best...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
So, there are mainly three approaches.
a big atom
This idea is not very atomic, but it works. This is useful if we need to persist data or push back to the server.
(Wait a minute, I might notice a missing optimization in the current implementation…)
There are utility functions to ease this pattern:
selectAtom
,splitAtom
,focusAtom
normalized data
Like you implied normalizr.
There are utility functions to ease this pattern:
atomFamily
atom references
This looks crazy, but it works.
This is pseudo code. We don’t manually create like this. It’s up to you at which level you top making atoms. For example, we don’t need to wrap with atoms for
planets
.To support this pattern, atom returns a unique string, so you can specify it to
key={}
.I would personally would like to recommend the third pattern. It’s pretty much like jotai, the power of it. Having nested atoms is tricky, though. I wonder how DX would be like. TS is almost necessary for this.
The first pattern would be good for persistence or server cache. The second one might be easier to understand, especially with
atomFamily
.Neither
focusAtom
norselectAtom
doesn’t have caching mechanism. If that’s ok, this should work?