I see that ngrx 4 now has its own implementation of createSelector(). However, will it still be compatible with reselect, should we choose to use it for some of the more advanced features that reselect offers?
I'm a bit concerned in particular about this bit of code here:
https://github.com/ngrx/platform/blob/48a2381c212d5dd3fa2b9435776c1aaa60734235/modules/store/src/store.ts#L73-L76
where it looks as if the code checks isSelector() (for which I think a reselect selector would return false) then wraps the selector in an ngrx selector if it is not a selector, possibly leading to the result being "double memoized".
+1, I am also confused about whether I should be using @ngrx/stores custom createSelector function or if it is still OK to use reselect. I think I am facing the same issue @karptonite pointed out as well.
I may also be confused about what sort of memoization is going on in createSelector vs what sort of memoization is going on in Store.select().
Ah, good point about that line of code. Our intention is certainly to maintain compatibility with Reselect because they offer more advanced features. I will happily accept a PR that simplifies that code path.
@MikeRyanDev One solution is to just remove the part of store where it wraps a selector in createSelector if it is not already a selector. That puts the onus on the user to add createSelector, but it also allows the user to omit memoization if they have a selector where memoization causes a performance hit.
In general, I'm not sure that the benefits outweigh the added technical debt for ngrx implementing its own version of reselect. reselect is a pretty small library. I know you need it if you want to add createFeatureSelector without adding a dependency on reselect, but a feature selector is such a simple selector that it seems overkill.
+1, totally agree. Setting up reselect is super easy and familiar, especially if you come from a redux background. If you really wanted to integrate the ability to create selectors into @ngrx/store, I'm not sure why you wouldn't just depend on reselect directly. But it also doesn't seem like something you'd want to force on developers either.
@karptonite Sounds like a good solution to me.
Also, our own memoized selector implementation is _very little code_. It was put in place so that we didn't need any dependencies and to put in groundwork for future improvements. It seems very likely that future ngrx libraries will be providing their own selectors.
I'll get out a pull request.
Most helpful comment
In general, I'm not sure that the benefits outweigh the added technical debt for ngrx implementing its own version of reselect. reselect is a pretty small library. I know you need it if you want to add createFeatureSelector without adding a dependency on reselect, but a feature selector is such a simple selector that it seems overkill.