I don't feel like there's a huge difference between seeing something like: I don't think that separating definition so far from usage here does you any good - it just makes it more difficult to see what is actually happening. It might even be worth having an explicit note in the docs themselves saying that certain generic values are considered internal and by manually setting them you're more tightly coupling your implementation to the current version, making it more liable to break for even minor future updates. But I doubt I'm the only one, unfortunately.
#REDUXJS TOOLKIT CREATESLICE CODE#
However, in this case, the args are more-or-less correct as far as I can tell (at least for now), in which case I guess the point is that future upgrades could introduce breaking changes, which again I would argue is no different to anything else and it's fairly normal to expect that upgrading a dependency could require refactoring your code slightly.įrom your POV I can definitely see how it might be worrying to have people overriding default args that you didn't anticipate they would.
the runtime args passed to the functions themselves) incomplete, incompatible or incorrect inputs will obviously cause problems. IMO generic args are part of the public API that you the library exposes and just like the rest of the public interface (e.g. I think it's fairer to say you shouldn't call the functions with incorrect or incomplete arguments right? (which is a bit of a truism). You should never call createSlice (or configureStore or most other RTK functions unless explicitly stated in the docs) with hand-written generic arguments. I really like this approach as you get the types flowing through into your payload objects inside your reducers functions.Ī) Is there a similar, built-in way of accomplishing the same? (without defining the reducers outside of the createSlice fn and letting the types get inferred - I find this less readable too)ī) Is this a pattern the maintainers would be interested in incorporating into the lib? Or is it too subjective/niche/complex etc?
0 kommentar(er)
