The state parameter of the addOne reducer is of type WritableDraft and the first argument of entityAdapter.addOne is Redu圎ntityState so the selectEntityState function is essentially just doing a type boxing while selecting only the properties of ISliceState that the entity adapter cares about. I can see why it might look confusing at first but while it might look unnecessary at first it is necessary for typescript. I think for that reason my package still provides value, but I am always on the look out for a way to accomplish the functionality of my slice factories in way that is both accepted and maintained by the redux community. While the tools Redux Toolkit gives us are amazing I didnt want to wire up my slices every time, especially when they all had the same functionality.
Ideally it would be nice to have a zero-config (yet highly configurable) slice factory defined in a project so that any slices within it have a homogenous feature set of actions and selectors. Given that context I think there might still be a need for slice factories but rtk-query will hopefully eliminate the any inconsistencies across slices when it comes to data fetching, and could eliminate the need for my package entirely. Both of these reasons lead me to figure out a solution that was generic, strongly typed, and worked well with RESTful endpoints.
It was also because the ways in which my team was deciding whether or not to request data was inconsistent. When I first wrote redux-slice-factory it was mainly because I was tired of rewriting slices and having inconsistent functionality between them (Note: I started writing it before redux-toolkit existed). Yea looking at rtk-query now and it looks awesome.
0 kommentar(er)
