Can we have Redux in Rust? (Yewdux)

[@aure555]

Absolutely loving the videos you've been putting out recently!! Covering so many topics that I've been meaning to dig my teeth into but haven't had a chance to look at. Keep it up

[@magnusmarkling]

Nice clip! It's most obvious that you are knowledgeable in both Rust and React.

[@intendednull]

Great video! Super comprehensive and easy to follow. Thanks! I'll get to work fixing the example :)

[@fenkraken]

This is very exciting news (and times overall) for WASM and WebDev in general, but I think Redux as a library (and as a pattern) has proven itself less than useful outside of concrete historic niche in React world when there was no good state management library. Single store (which was described as necessary for pattern to differentiate from Flux and many others) is both impractical in terms of usage and DX and also in terms of code-splitting. People were creating hacks to code-split their applications to ship parts of the store that was specific to the module so the bundle wouldn't look insanely bloated. So I don't really understand the reason why would anyone wants it, unless they specifically don't want to learn much easier store solutions and just want to port their apps to Rust from React+Redux almost verbatim (why though?). Even the main author of it doesn't endorse it in its purest form (I think it's recommended to use redux-toolkit in React beta docs). I would much rather see people porting innovative stuff like Solid instead of porting JQuery of React ecosystem.

[@9SMTM6]

Hmm. Regarding the creation of HTML snippets in the component body. I think it probably still isn't what I'd recommend, but it should be a LOT less problematic in Rust with Yews functional component than in JS/TS with React Class components. Two reasons. First Rusts mutability rules mean it's less likely you're gonna generate hard to trace dependencies/ changes, which is always possible in these render methods in JS/TS React Class components. Then, and this would/does also apply to React class components, it's less likely you're going to create a lot of "methods" that are just for that specific "render method". A class with seperate methods sometimes creates a fiction of order. It's all different methods after all. So people create a method here and there that are actually created for the rendermethod, and then only if you actually want to change things you notice what a Spagetti you've made, with it being unclear what method belongs where, some used only for this and that render method, some being used by all etc. With a functional component that semblance of seperation between "methods" just isn't a thing, and all the "methods" will be before the return (=HTML), so it's a lot more obvious when you've overloaded it with seperate things. Still, while a seperate component will need some more boilerplate, it's usually worth it in terms of explicit dependency tracking.

[@lcarv20]

Loved the vid, but in my opinion I don’t recommend redux style for state management. It’s hated in the react ecosystem for a good reason, but that’s just my opinion. Keep the good work.

[@chrisbiscardi]

glad you enjoyed the video! I would caution thinking that too many people are dropping redux though. Its usage has steadily grown ever since its release and is doing something like 10 million downloads/week these days. Anything with that many downloads is going to have people who are very loudly "anti" that thing. Yes there are some loud people who don't like redux, and not liking it is totally valid, but that isn't actually reflected in its usage graphs. For every 2 downloads of React, someone is downloading Redux.

[@lcarv20]

@@chrisbiscardi it’s true, and my opinion is based on personal tries plus what the creator of redux said once. But I assume you can confirm, because something is downloaded often doesn’t mean it’s the best solution. It’s like Java, it has many problems with design decisions, however is still one of the most used languages, and it’s still downloaded and used a lot. People use and learn what the market already has. I had to learn redux as well, and I had to use it as well, but in the react ecosystem I prefer libraries like zustand and immer for state management. Again this is personal opinion.

[@ironhammer4095]

@@lcarv20 Wasn't the problems with Redux addressed with Redux Toolkit? from the docs: The Redux Toolkit package is intended to be the standard way to write Redux logic. It was originally created to help address three common concerns about Redux: - "Configuring a Redux store is too complicated" - "I have to add a lot of packages to get Redux to do anything useful" - "Redux requires too much boilerplate code" There was a trend to move away from Redux for these reasons but I think the trend has moved back towards Redux.

[@magnusmarkling]

What do you do to show and hide the type hints in vs code?

[@chrisbiscardi]

rust analyzer used to have a toggle inlay hints setting, but they recently moved to natively supporting VSCode's method of displaying inlay hints, so I use a third party plugin to bind C-i to toggle turning inlay hints on and off as detailed here: github.com/rust-lang/rust-analyzer/pull/13215#issuecomment-1252443157

[@climatechangedoesntbargain9140]

still far to go to come close to ngrx

[@chrisbiscardi]

Probably won't ever be similar to ngrx since the goals are very different considering that ngrx exists to integrate with rxjs and yewdux does not use any reactive libraries

[@climatechangedoesntbargain9140]

@@chrisbiscardi I don't care about similarity or implementation details, but about functionality. Yewdux could have it's own rxRust or depend on an existing attempt, feature decoupling of event handling and triggering, Redux devtools integration, and more.

[@MudroZvon]

I like your videos, but fuck redux! Let this shit stay in js

[@chrisbiscardi]

Glad you're enjoying the videos! In general I don't allow comments on my channel to bash technology like this. You're fine to not like something, but just saying "fuck X" isn't going to stay up. Real people do work on these technologies and we don't need to participate in arbitrary "us vs them" arguments around here.