RFC - do you mind adding some helpers related to Observables and or TypeScript types?

[dmorosinotto]

I think that this repo/project is mostly related to Angular helpers, but do you mind if I add something related to Observable operators: https://gist.github.com/dmorosinotto/f98370a39d9041358915b8a493cf3654 or TypeScript generic types helpers? https://gist.github.com/dmorosinotto/394ad458bd5352c3869981771baeaf1d I have even others but just asking what you think before opening proposal issues that maybe are not in scope/desired...

[nartc]

I think the RxJS operators make sense to include but the TypeScript helpers aren't a bit of an outlier. Thoughts?

[dmorosinotto]

Yes I suspect it, maybe I pick one sample types that is not really related to "Angular" I have other Generic types that I wrote and use in different project, but maybe it's out of scope for this library I agree

[dmorosinotto]

For the Observables operator if you think that they be acceptable I will go to separate issue (feat add proposal) so you can evaluate it separately , or give me and hit on how you prefer to handle it (sorry I'm bit "newbee" to the open-source collaboration flow)

[nartc]

Separate issue would be great. And you can close this one with a reference to the other one. (or I can close it once you have a new issue up)

[dmorosinotto]

@nartc sorry for the delay but was so busy in the latest week, I'll probably had some free times on this weekend to implements the RxJS operators that I mentioned, but before opening a PR I want to discuss with you and others @tomer953, @JustroX, @tomalaforge that had running issues about adding RxJs operators if we'll keep creating separate entry point one for each operator, or if we can take a different approach and organize all of them under a common ngxtension/rxjs or ngxtension/operators and put all of them under this entrypoint as single export functions so it'll be easier to pull-in the operators we need without pointing to single different files, or maybe create other sub-entry point for single operators under it ex: ngxtension/operators/filterNil? What do you all think?

[tomer953]

Pretty sure @nartc has referred to this somewhere in the issues, the “flatten” approach is better duo to the secondary entry point feature, if you go one more level, another package will be needed to be a wrapper. (not sure at all)

The library is entirely consisted of Secondary Entry Point. Even though we ship ngxtension as one package (so it is easy for consumers to install), Angular build pipeline should handle code-splitting and tree-shaking properly for all the entry points that ngxtension comes with.

[dmorosinotto]

Yes @tomer953 I know and read about Secondary EntryPoint in docs, and I'm NOT an Expert on module organize/publishing, don't know if we need another package to handle the "Third" entry-point, but I believe that the reason for secondary entrypoint is enable treeshaking for bundle - and maybe I'm wrong, but having separate exports function in the same module just enable it - thinking about how it's done in RxJS imports { map, filter } from 'rxjs/operators' teorically doesn't pull in ALL RxJS to our final code bundle?!

[tomer953]

Not expert either. And rxjs actually changed the way you import to the flatten approach as well…

With RxJS v7. 2.0, most operators have been moved to 'rxjs' export site. This means that the preferred way to import operators is from 'rxjs' , while 'rxjs/operators' export site has been deprecated.

[dmorosinotto]

Yes and in RxJS you don't get the entrypoint for single operator you can NOT import map from 'rxjs/operators/map' (as far as I know) , but you still get tree-shaking (or I'm totally wrong)