Many updates during transitions, future plans

[gurkerl83]

I am experimenting with the codehike source, especially with the Scrollycoding component and its subcomponents.

The component EditorSpring and, more specifically, in the hook useStepSpring, another hook useSpring gets used, providing the progress. The progress property is passed down to all components down to the very leaves; when a transition executes, a ton of updates get triggered. The progress or t property gets used quite frequently in those sub-components. My question here is; is it possible to separate transitions used in the editor, its subcomponents, and the content components like SmoothLines?

A lot is going on in the respective components, and a vital requirement for memoization. The combination of tons of updates makes it hard for me to contribute.

Animation is complex, and the use case is large, with many variants. In terms of animation, maybe other libraries can help using certain features which are very hard to come up with otherwise, such as framer-motion. Before I invest too much time, do you have a rough roadmap and future plans for codehike. I saw your bright repository using sever components to reduce or eliminate increases in the bundle size of a page. Maybe you can clarify the priorities of those two projects and or plans to integrate one into another.

Also, the bundle size of codehike adds some pretty extra load; in my case, it is about 100KB, but sure is used only in some places, only when you show code snippets.

Thx!

[pomber]

Hi. Good questions.

I'm experimenting with bright and React Server Components to approach the problem from the static zero-JS angle. In a world where all the major frameworks adopt RSC it would simplify a lot of the work in Code Hike but not sure when or if that will happen.

the bundle size of codehike adds some pretty extra load; in my case, it is about 100KB

100KB all from Code Hike? According to my tests, an MDX page in Next.js without any components ships around 75KB, one using the Scrollicoding component from Code Hike ships around 110KB (the part of Code Hike that only runs on the server is bigger, but it won't ship to the client).

The progress property is passed down to all components down to the very leaves; when a transition executes, a ton of updates get triggered. The progress or t property gets used quite frequently in those sub-components. My question here is; is it possible to separate transitions used in the editor, its subcomponents, and the content components like SmoothLines?

Code Hike started more as a code animation library, that's why rendering each frame inside of React made sense. Now it's kind of a problem because most websites don't care that much about the animations or only care about basic "diff" animations. Other features like auto zoom are almost never used but had a lot of influence over the code and architecture of Code Hike.

I'm watching the RSC space closely because it would help with your concerns. It would make it much easier to decide on the server what features to ship to the client.