Align self center

[chrsan]

Hi!

I think there’s a bug when calculating center alignment for self. The element width is used twice, and I suspect that one of the values should be the width of the parent? I’m not quite sure about the x/y values calculated in the same step.

Out of curiosity, what does the check for if a child input with or height is a number do when determining the parent width or height do? Those values are never used in those steps?

Thank for a nice blog about Flexbox layout post by the way!

[tchayen]

Hi! Thanks a lot for identifying and digging into this issue! I can't look at it right now but I should be able to fix it in the next couple days. Feel free to ping me if there's no update from me!

---

Not related to the issue but to give more context on what's happening with the library – I haven't published any update in a while but I've been experimenting a lot behind the scenes.

For some reason a had a class phase when writing Red Otter, resulting in multiple classes being created, but now that I think about it many of the steps involved are actually just direct data transforms – I take some information and produce another information. There was no need to make them classes, it was just a matter of dividing execution steps into proper chunks and figuring out what depends on what, nothing more 😄. That way I was able to turn multiple classes into functions, which should result in slightly better tree shaking.

On the topic of lack of updates – the build system that I ended up with – it scares me. I need to produce CJS and ESM outputs, convert TS to JS, test all output combinations. That's a lot of work and I'd rather be free to continue research than worry what I broke this time when publishing a new version. There are some libraries in the ecosystem (I think Svelte got the most publicity for it lately) that decided to rewrite from TS to JS with JSDoc types. I like how it simplifies the build pipeline but I am not ready to drop TS which I personally really like and feel that it helps my productivity (and I am not particularly fond of JSDoc types; I believe in their expressiveness but I don't really want to write the complex types myself). On the other hand I see that library authors recently are getting more and more vocal about dropping CJS and publishing just ESM. I feel like it is inevitable in future and since this library is highly experimental, I am considering jumping on that train and from now on publishing only ESM. That would simplify things a bit for me.

Also I am working on refining the layout algorithm so that it's idempotent and can be run multiple times without messing up the layout. Currently it's not and it I think adds paddings infinitely. This will be important for implementing interactive GUIs on top of it, which I am working on right now.

And I wrote WebGPU renderer. It follows slightly different principles due to architecture differences in WebGPU vs WebGL so I need to think whether it can be added to the lib as is or should either of them be adjusted a bit.

So to sum up:

• More functions less classes which will improve tree shaking.
• Probably dropping CJS in favor of just publishing ESM bundle.
• Better layout algorithm.
• WebGPU renderer.
• In future: full interactive UIs.