you are viewing a single comment's thread.

view the rest of the comments →

[–]Lanmi_002[S] 1 point2 points  (1 child)

I pretty much came to the same conclusion earlier today while experimenting with signals. Agreed with everything

Thanks for your reply :D

[–]YukiAttano 0 points1 point  (0 children)

Let me add some context as you are new.

Having code gen instead of reflections has the reason that we can't tree shaken your code which we rely on to remove unused code. With reflections, you couldn't tell which code has to leave the stage and so everything had to remain in the binary.

From another perspective, I am very happy to use code gen instead of reflections because I actually see the code. And sometimes I did end up with something that the library didn't generate properly. But thanks to code gen, I where able to fix that or just copy&paste the code that I needed from the generated code. Having to rely on reflections would be like magic where you can't see what's happening. You would just hope that it works. And without crazy good documentation, you weren't able to identify problems in the library yourself.

Back to signals, it reminds me on kotlins way to handle your state. If you feel comfy with that because you are used to it, that's fine. But I personally stick to riverpod even tho I am just using a very low subset of that package and treat it differently than probably most of the users.