orizens / ngrx-styleguide

a collection of best practices / commonly used patterns with ngrx extensions - store, effects, router and others

ngrx Style Guide

Purpose

The idea for this styleguide is to present commonly used techniques for working with ngrx suite and serve as a kind of a cookbook/recipes with a problem/solution theme.
The purpose of this style guide is to provide guidance on how to integrate ngrx-X-tool by showing the conventions used by users of the community.

Introduction Blog Post

Projects Following The Styleguide

• Echoes Player

Please open an issue to add your project/suggestion

---

Table of Contents

1. Creating A CoreStoreModule
2. Store Single Directory
3. Reducers
4. Actions

not added yet

1. using Side Effects
2. consuming reducers in components
3. using selectors

Copyright (c) Oren Farhi

Back to top

ngrx-styleguide's Issues

Extend Readme to include "using selectors section"

at the "Reducers Included Files" you placed a ".selectors" file in the folder structure.

- src
  - app
    - core
      - store
        - now-playing
          - index.ts
          - now-playing.reducer.ts
          - now-playing.spec.ts
          - now-playing.actions.ts
          - now-playing.selectors.ts

I'd really appreciate if you'd show an example of that kind of file

features selectors

in ngrx we can use layzy loaded future selectors, consider to add it

Blog post 404

When I click in blog post I have 404 status.

Store directory location.

At https://github.com/orizens/ngrx-styleguide/blob/master/docs/store-single-directory.md you say, and repeat it in next rules, that store directory with reducers, selectors, side-effects and e.t.c. must be at core-dir. But, what's about at least lazy loading (that is accepted as best practice)? If I need that states only at this module, i would look for it there, it's intuitively and popular decision, for component and microservices architecture. And why, if i use many of modules in my project, and have many of reducers and states in it, i should transform my core store module into a trash? That's out of sense at my point of view. I agree, that relying on the SRP we must have a single point of truth, but these are not interconnected things. https://ngrx.io/guide/store/reducers - official guide, that say's about right modules architecture. If you mean store-single-directory only within the module, it is worth clarifying.

Store Single Directory rule and feature lazy loaded modules

How the Store Single Directory rule plays with the feature modules that are loaded lazily? It's reducers should be also loaded lazily so cannot be provided by the core module,

Angular style guide may conflict with regard to capitalization

Here is a snippet from your guide and then a snippet from Angular's guide. Angular seems to "prefer" lowerCamelCase over UPPER_CASE.

ngrx-styleguide:

naming actions (for state)

Note: look at actions for side effects here
DO name actions with a unique name and captial letters - VERB + NOUN.
DO name actions values with - Prefix + VERB + NOUN.
Why?: it's readable.
Why?: actions can be filtered and viewed in redux dev tool easily.
Why?: uniqueness is for making sure only one reducer handles the action.

const UPDATE_FILTER = '[PlayerSearch] UPDATE_FILTER';
const ADD_RESULTS = '[PlayerSearch] ADD_RESULTS';

https://angular.io/guide/styleguide#constants says:

Consider spelling const variables in lower camel case.

Why? Lower camel case variable names (heroRoutes) are easier to read and understand than the traditional UPPER_SNAKE_CASE names (HERO_ROUTES).

Why? The tradition of naming constants in UPPER_SNAKE_CASE reflects an era before the modern IDEs that quickly reveal the const declaration. TypeScript prevents accidental reassignment.

Do tolerate existing const variables that are spelled in UPPER_SNAKE_CASE.

Why? The tradition of UPPER_SNAKE_CASE remains popular and pervasive, especially in third party modules. It is rarely worth the effort to change them at the risk of breaking existing code and documentation.

app/shared/data.service.ts
content_copy
export const mockHeroes = ['Sam', 'Jill']; // prefer
export const heroesUrl = 'api/heroes'; // prefer
export const VILLAINS_URL = 'api/villains'; // tolerate

Also, there is an interesting comment at reduxjs/redux#1097 from the creator of Redux:

Please use any style you consider appropriate. There's nothing particularly "right" about the style we use in docs. We always discuss important parts (such as reducer purity). The rest is up to you.

Would you agree, based on this information, that we should use lowerCamelCase for our exported action variables?

Chunking the core

I love this style guide, this is not an issue more a question, when using Angular Cli in order to generate a project I feel that the core / main.js bundle is going to start getting to large do you have any ideas on how to get around the Angular cli config in order to have a separate file for the core module code?