Batch creating children
I want to create a canvas api with solid and for this I want to batch adding children to the canvas so I only draw them once they are all added, (or one is updated).
My basic idea was to just have a context called ObjectCtx which is just a signal of an array and have the children add themselves to this, but this always happens one by one.
How would one go about combining them. I am open to suggestions here.
11 Replies
There are 2 approaches that come to mind: 1. instead of signal use some custom setter that batches updates or additions and then runs them together using queueMicrotask() (but probably not since it is used by solid internally so there could be some problems) or requestAnimationFrame() or use something that already exists like 'fastdom'. 2. Or instead of using contexts you can pass the information in form of tokens https://primitives.solidjs.community/package/jsx-tokenizer#createtoken then resolve them in parent element (changes will be bached) and in some helper like mapArray or indexArray apply the changes
Solid Primitives
A library of high-quality primitives that extend SolidJS reactivity
Interesting, but the token package seems to have been rejected, I checked the code and it uses createComponent funciton, I find that in the code of solid, bit it is not in the solidjs documentation.
You might like https://github.com/bigmistqke/solid-canvas
GitHub
GitHub - bigmistqke/solid-canvas: (WIP) 🎨 A Canvas API-wrapper f...
(WIP) 🎨 A Canvas API-wrapper for solidjs ⚡ by solid and @solid-primitives/jsx-tokenizer - bigmistqke/solid-canvas
I made it around the same time as I wrote that jsx-tokenizer stuff
Problem with using context for building up a scenegraph is that you will not be able to express the order of siblings consistently, for example because of some conditional rendering.
And for 2d stuff that is kind of important, if you want to make the order of the elements decide the render order.
So I think resolving children is a better way of doing it, because then you can always be assured it's the right order.
Nowadays I don't use the jsx-tokenizer package anymore, I simply return
{ } as unknown as JSX.Element if I wanna do similar stuff
Wdym with rejected btw?Thx for your suggestion, I am just using an object as you suggested, seems to work ok for all my current use cases.
The jsx-token page has a red status, https://primitives.solidjs.community/package/jsx-tokenizer
Solid Primitives
A library of high-quality primitives that extend SolidJS reactivity
I just checked and on the homepage it it has stage 2, but on the project page is is red, that is what i meant with rejected
Dunno what is right
You are very welcome! The jsx-tokenizer package is basically a wrapper around the pattern of returning an object. It attaches a symbol to it so you can be 100% sure that the child is the thing you think it is.
Ye, that is a bit odd! @thetarnav do you know what's up with that? Are we deprecating jsx-tokenizer?
Btw, kinda fun aside: the
jsx returning an object pattern is also how solid's Switch/Match and Router/Route works! It is canon 😊It is def a nice and simple way to solve this problem.
I was over thinking it with the context and registration pattern
that’s a bug on the website I think
It's a pity that jsx is opaquely typed, otherwise people would far more easily start doing these type of patterns. Think you will like https://github.com/BobochD-Brew/battuta that project is all about pushing these type of jsx hackery to the max. They even have a typescript patch too that allows the jsx to be typed non-opaquely so you can like be like
only allow type X as a child and a <div/> is actually a HTMLDivElement!
We yap about it over hereGitHub
GitHub - BobochD-Brew/battuta: experimental frontend/composition fr...
experimental frontend/composition framework. Contribute to BobochD-Brew/battuta development by creating an account on GitHub.
https://github.com/BobochD-Brew/battuta?tab=readme-ov-file#constructors is a really cool feature
Makes that you can do stuff like