use-context-selector VS Svelte

Use jotai, or as someone else mentioned, zustand. React Context out of the box requires a very deliberate mental model due to a lack of tooling around selecting slices of state. This is why packages like react-context-selector exist: https://github.com/dai-shi/use-context-selector

Unless I've missed it, context doesn't have selector IIRC. You'd have to use a third party solution useContextSelector

How does this differ from https://github.com/dai-shi/use-context-selector?

you can always split out context state or use a library to help with rerender issues like https://github.com/dai-shi/use-context-selector, or just switch to jotai or something else if you want something more ergonomic or better design patterns.

If you don't want to swap out useContext, you could always use useContextSelector, which helps you limit what props in the context should rerender the component.

I wouldn't call this easy

It wouldn't be clear to anyone learning Context API either. At least, not using official docs. Because Context API is not supposed for state management, and if you for some unknown reasons try to roll your own state management on top of it, you have to use tricky libraries to work around the issues resulting from such abuse.

Any time anything in the context changes, any component that is consuming it will re-render. If you use it for frequently changed values, this library is needed to reduce unnecessary re-renders.

Use of this implementation of useContextSelector

Another technology I use regularly is Redux. But this time I wanted to manage the global state in a simpler and clearer way just using React hooks. I decided to go with a simple useReducer combined with theuseContextSelector hook which will avoid the whole application’s re-render caused by the native useContext hook.

the technical decision how Svelte should treat self-closing html elements was hindered by Prettier:

Svelte

React has introduced measures like batching state updates, background concurrent rendering and memoization to tackle this. My opinion is that the best way to solve the problem is by improving their reactivity model. The app needs to be able to track the code that should be re-run on updating a given state variable and specifically update the UI corresponding to this update. Tools like solid.js and svelte work in this manner. It also eliminates the need for a virtual DOM and diffing.

Similarly to Promises/A+, this effort focuses on aligning the JavaScript ecosystem. If this alignment is successful, then a standard could emerge, based on that experience. Several framework authors are collaborating here on a common model which could back their reactivity core. The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

Svelte is a powerful web framework that offers a fresh approach to building web applications. Its simplicity, reactivity model, and built-in features make it an excellent choice for developers looking to create efficient and maintainable applications. By following this guide, you should now have a good understanding of how to get started with Svelte and build your first components, routes, and transitions. You can read more about svelte on the official Svelte website.

Use .NET features (especially dotnet watch) as a setup for a client-side Svelte application, starting from a simple C# console app.