Select Combinations about store

[amcdnl]

@deebloo - I have an idea for this, will be pretty easy to implement too.

@State({ ... })
export class ZooState {
   @Selector({
       combine: [CowState.cows, ...n*]
    })
    static animals(state: ZooStateModel, cows: Cows, ...n*) { ... }
}

[leon]

I would prefer

@Selector([CowState.cows, FarmState.milktime])

[amcdnl]

Ya, I was trying to keep it where if we wanted to add other options down the road it would be easy but ya I agree

[markwhitfeld]

I have spent some time thinking about this feature.
I have tried to define clear rules on what would be expected from this.
Here are my thoughts on this:

• (This is the existing usage) A @Selector decorator with zero parameters is only valid in a state class and provides the container class' state model as the only parameter :

@State<UserStateModel>( ... )
export class UserState {
  @Selector()  
  getUsers(userStateModel: UserStateModel) { ... }
}

• Allow state classes to be passed in as parameters. This can be used from within any class, be it a State class or another service class. It only provides the models as requested (ie. it does not add the model for the containing class, no matter if it is defined in a state class or not) :

export class SomeStateClassOrRegularService {
  @Selector([UserState, TodoState])  
  getActiveUserTodos(userState: UserStateModel, todoState: TodoStateModel) { ... }
}

• Allow selectors to be passed in. The rules would be the same as passing State Classes as parameters:

export class SomeStateClassOrRegularService {
  @Selector([UserState.getName, TodoState.getCount])  
  getUserTodoCount(userName: string, todoCount: number) { ... }
}

• Or a mix of the two:

export class SomeStateClassOrRegularService {
  @Selector([UserState.getName, TodoState])  
  getUserTodos(userName: string, todoState: TodoStateModel) { ... }
}

• A @Selector with no parameters would not be valid on a class that is not a state. There was an option that the global state could then be passed as the parameter, but this would break encapsulation because it would require the dev to have knowledge of the global state structure.
  To be clear, this would not be valid:

export class MyNonStateClass {
  @Selector()  // ERROR!
  static invalidSelector(thisIsNotValid: any) { ... }
}

Regarding the possibility later of adding options, I think that the options could be expressed as an object and the decorator could detect if an options object or an array was passed to it or both. As an example the only thing I could think of now that may be an option we could add in future is a different memoiser, so this is what this could look like:

export class SomeStateClassOrRegularService {
  @Selector([UserState.getName, TodoState], { memoizer: customMemoizer(3) })  
  getUserTodos(userName: string, todoState: TodoStateModel) { ... }
}

PS. selector option given as an example but I don't think we need to implement the options part until there is an actual need for it.

[amcdnl]

What would be the use case for a selector that doesn't belong to a state?

[markwhitfeld]

I think that the idea would be that if you need to create a selector that does a query across multiple states in your application and they do not share a common heirarchy (other than app state) then you could put this selector in a class not directly associated with a particular state class.
@leon mentioned this concept on slack in this comment: https://ngxs.slack.com/archives/CA0NS79MG/p1524210374000089
Maybe @deebloo can chip in here too.

[juliusstoerrle]

Use Case for Seperate Selectors:
If I have a user module and multiple modules with relations to the user module and I want a selector pulling in a user with its related items. I would like to have this selector separate from any State. Because if I would put it in my UserState it break lazy loading of user related feature modules.

@markwhitfeld thats some great work, I like those ideas. I think most important is passing in other selectors.

[amcdnl]

Closing and marking for future.