feat(store): add tree shaking states into integration example

[splincode]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngxs/store/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

#629

What is the new behavior?

Root provides

todos.state.ts

@State<TodoStateModel>({
  name: 'todos',
  defaults: {
    todo: [],
    pizza: { model: undefined }
  },
  children: [TodoState], 
  providedIn: 'ngxsRoot'
})
export class TodosState {
  ...
}

todo.state.ts

@State<string[]>({
  name: 'todo',
  defaults: []
})
export class TodoState {
 ...
}

app.module.ts

@NgModule({
  imports: [ NgxsModule.forRoot() ]
})
export class AppModule {}

app.component.ts

@Component({ ... })
export class DetailComponent {
  @Select(TodoState) todo$: Observable<string[]>;
  @Select(TodosState) todos$: Observable<string[]>;
}

Lazy provides

detail.state.ts

@State<DetailStateModel>({
  name: 'detail',
  defaults: { foo: true },
  providedIn: DetailModule
})
export class DetailState {
 ...
}

detail.module.ts

@NgModule({
  imports: [NgxsModule.forFeature()],
  declarations: [DetailComponent]
})
export class DetailModule {}

detail.component.ts

@Component({ ... })
export class DetailComponent {
  @Select(DetailState) detail$: Observable<DetailStateModel>;
}

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Update integration example with tree shaking states

[viters]

@splincode

What are the benefits of this approach, instead of previous imports: [ NgxsModule.forRoot([TodosState, TodoState]) ]?

While I am really keen of angular tree-shakeable services, it seems impossible to me to 'tree-shake' a state. Tree-shaking process isn't only about adding providedIn, but about removing unnecessary code. And here is my wrinkle: how can you tell, if state is being used or not in whole project at compile time (keeping in mind dispatching actions).

Beside that, it's true that this approach complies with "new angular way" for services - but why it uses keyword provideIn while angular core uses providedIn?

[arturovt]

@viters

There was a typo in the provideIn keyword, already fixed.

You are totally right - you cannot tree shake any state, BUT only using native approach with @Action.

We've recently published a package that allows you to get rid off actions (emitter), thus tree shaking works great with this approach.

[viters]

@arturovt

Awesome. Thank you for clarifying.

[arturovt]

Change to providedIn

[markwhitfeld]

@splincode Doesn't the lazy example above result in a circular reference?
DetailState --references--> DetailModule
DetailModule --references--> DetailComponent
DetailComponent --references--> DetailState

[markwhitfeld]

I feel like this feature is trying to solve something that is not a problem.
The providedIn in angular is to provide tree shakeable services exposed from libraries so that when they are included in a client app by being injected into something they will be automatically registered with the root module.
Our state classes are a very different paradigm to services.
There is no clear benefit to NGXS from this feature.

[splincode]

@markwhitfeld

I. Question

Doesn't the lazy example above result in a circular reference?

Answer: No. It works exactly the same as in Angular. Just injected into the module.

Analogue:

@NgModule({
  imports: [NgxsModule.forFeature([ DetailState ])],
  declarations: [DetailComponent]
})
export class DetailModule {}

II. Question

I feel like this feature is trying to solve something that is not a problem.

I write huge applications consisting of a set of modules, sometimes components or modules are deleted and we forget to remove the state from the module. Together with @kyusupov33, we determined that the big problem is the implicit initialization of states.

https://github.com/ngxs/schematics/blob/master/src/templates/starter-kit/store/store.config.ts

It turns out that when we have a huge number of states, we are uncomfortable working with it.

III. Question

There is no clear benefit to NGXS from this feature.

Believe me, this feature is worthy to outshine even NGRX.

• The bundle will not get states that are not used in the root and child modules if they are not used.
• Even if you use only the root module, you will simply be able to write providedIn: 'ngxsRoot'.

I am ready to write a huge number of tests for you to believe me.

Motivation

If we usage Emitter plugin, we are improving for Tree Shaking, because since we use state class references

@State({  })
export class AppState {

    private static tagService;

    @Emitter(AppStatusState.success)
    public static success: Emittable<NormalizeTag>;

    @Emitter(AppStatusState.failure)
    public static failure: Emittable<string>;

    constructor(tagService) {
      AppState.tagService = tagService;
    }

    @Receiver()
    public static request(ctx: StateContext<TagsStateModel>, { payload }: EmitterAction<NormalizeTag>) {
        return this.tagService.addOne(payload.newTag).pipe(
            tap(tag => this.success.emit({ tag: normalizeTag(tag), parentName: payload.parentName  })),
            catchError(error => this.failure.emit(error.message))
        );
    }

}

[splincode]

@markwhitfeld Since I will not be able to get your approval, I will close this thread and later will conduct an experimental development.

https://github.com/ngxs-labs/tree-shaking-state