Между чем и чем?

А разве у вас там distinct под капотом тоже в select?

Да

Ну если завязываться с closure, то много чего из стороннего может перестать работать

И даже по объектам и массивам?

Весь ComponentStore компактненько помещается в один файл (+ один оператор, который внутренний): https://github.com/ngrx/platform/blob/65e26132b9effe5d634bc3c53a4e1e89e5d61104/modules/component-store/src/component-store.ts#L223

Да, вижу. Но даже по небольшому опыту работы, без аналогов slice и кастомного distinct сложно

selectSlice('foo')
vs
select(state => state.foo);
🤔 не вижу большой разницы

в глобальном сторе все селекторы тоже distinctUntilChanged и "расшарены" за счет мемоизации :) Жалоб не послупало. :)

@matochu на самом деле фидбэк очень полезный - я буду знать на что обращать внимание :)
Спасибо. Если что-то еще будет - пожалуста скажи.
(док с примерами с Usage / use case будет в течении недели)

Да, я как раз из личного опыта.
На одном проекте сам писал кастомный distinctUntilChanged по полям, так как в той же сложной форме нужно было. В локальном сторе тоже пригодилось уже не раз. Потому как сравнение по ссылке не удовлетворяет, когда не очень ясно насколько изменился стейт.
SelectSlice удобен, когда в таком сторе хранится как инпут от компонента, так и данные, которые можно получать ассинхронно по этому инпуту. Тогда чтобы не зацикливать весь стор, нужен механизм наблюдения за несколькими полями (с одним и map/select) справятся.
Описание таких юзкейсов будет полезно.

Тут скорее selectSlice(['foo', 'bar']), иначе это просто pluck

Тогда это будет что-то select(({foo, bar})=> ({foo, bar}));

https://meet.google.com/xjg-vqhg-hij
через 5 мин буду делать презентацию по ComponentStore

@AlexOkrushko Классная презентация, буду продвигать идею локал стора в компании.
Ещё один расплывчатый вопрос интересующий меня.
В эффекте который ты показывал на презентации довольно много логики и она не очень легко читается (особенно теми кто имеет не много опыта с rxjs) , и я часто вижу такое же в проде. С точки зрения чистоты кода, не должно ли это разбиваться на какие-то под-функции, или это правильный подход для реактивного кода?

@AlexOkrushko спасибо за доклад,  очень помог в некоторых пробелах!

@AlexOkrushko а запись случайно не делали?

Вроде как запись делали.

Спасибо!
в эффекте все довольно структурировано получается, и почти всегда по одному и тому же шаблону:

  // все вызовы getAuthor('id1') проталкивают в этот 👇 Observable
 readonly getAuthor = this.effect((ids$: Observable<string | undefined>) => {
    return ids$.pipe(
      // иногда отфильтровать сначала надо
      filter((id): id is string => !!id),
     // очень часто с вызовами API сначала на спиннер поставить
      tap(() => this.updateStatus('loading')),
     // вот тут мы выбираем оператор для избежания race conditions
      switchMap((id) =>
       // вызов самого сервиса
        this.authorService.getAuthor(id).pipe(
          // здесь мы на самом деле засунем полученные данные в сам сейт
          tap({
            next: (author) => {
              this.setAuthor(author);
              this.updateStatus('loaded');
            },
            // и обработаем ошибку
            error: (e) => this.updateStatus('error'),
          }),
          // убедимся, чтобы ошибка не закрывала наш еффект
          catchError(() => EMPTY)
        )
      )
    );
  });
}

мало что будет сильно отличаться