[docs] categorise utils about ngxtension-platform

[tomer953]

I Agree (and suggested it before)

lets suggeste categories?

• RxJS Operators
  • filterArray
  • filterNil
  • mapArray
  • reduceArray
• Directives
  • repeat
  • resize
• Pipes
  • CallPipe / AsyncPipe
  • TrackById / TrackByProp
• Signals
  • computedFrom
  • connect
• Inject utils (?)
  • assetInjection
  • createInjectionToken
  • injectDestroy
  • injectNavigationEnd
• Misc.
  • createEffect
  • IfValidator / IfAsyncValidator
  • Intl

[tomer953]

I think it would be lovely to structure the body content, not just the menu.

To have a standard, like this:

1. Introduction - What is it? Why do we need it? In two words - The problem.
2. Usage - Importing & examples with descriptions.
3. Configurations - Examples and descriptions, including default options if any.
4. Error Handling and/or Fallbacks.

This is just an idea, is just what I have in mind now.

Also, the body should contain 1 or 2 backlinks if it's the case, especially for newbies that will explain why you should use this over that. 🤷🏻‍♂️

I agree, a template for the doc should be very useful.
I made a pr #71 last week trying to convert the majority of the utils to the same template.
The lib is growing fast so its hard to maintain, but I suggest that for new utils to just copy-paste an existing doc file and modify it

For the categories, ill try to PR in a few days

[tomer953]

updated with some examples

[wanoo21]

I think it would be lovely to structure the body content, not just the menu.

To have a standard, like this:

1. Introduction - What is it? Why do we need it? In two words - The problem.
2. Usage - Importing & examples with descriptions.
3. Configurations - Examples and descriptions, including default options if any.
4. Error Handling and/or Fallbacks.

This is just an idea, is just what I have in mind now.

Also, the body should contain 1 or 2 backlinks if it's the case, especially for newbies that will explain why you should use this over that. 🤷🏻‍♂️

[e-oz]

I would add the "State Management" category.

[LcsGa]

Instead of directives, pipes, etc. categories, and as sometimes we could have different types in one feature + as the name state the lib is tought to be an extension of angular 👉 shouldn't we try to put them in the same packages as angular (eg: core, core/rxjs-interrop, common, etc.) (We could also create new ones if we feel like there is a missing spot in angular, like for state management like @e-oz said)

[tomer953]

Can you provide example with the current utils? not sure how well its fit

[LcsGa]

For example:

• computedFrom or connect are used for rxjs interoperability 👉 they could be placed into core/rxjs-interop
• trackBy is a tool of NgFor which is in common 👉 thus we could add TrackById / TrackByProp into common
• the AsyncPipe is also part of common 👉 we could add CallPipe / AsyncPipe into common too
• assertInInjectionContext is witin core 👉 we could add assertInjection within core
• rxjs operators, on the contrary, could be placed within a new package as I personnaly don't think that it should be placed within the interop package (I may be wrong)
• etc.