Cat Chat Organization

App Module
UI Module
      Container Components
      View Components
Network Modules
      Group Chats Module
      Like Message Module
      User Module
      Web Socket Module

Modules

Cat Chat's code is organized into a collection of Angular modules.

App Module (src/app/root-module/)

App Module is the root module for the application. It contains the component that is bootstrapped at application launch, along with any services that should be made global to the application.

Since this is our root module, we also import certain external modules here that are needed throughout the rest of our application; prime examples being:

• NgxsModule.forRoot()
• BrowserModule

The AppComponent class that gets instantiated at application launch retrieves the user's authentication token from the body of the html page, and updates the value held in AuthService. It then passes execution on to the UI module.

UI Module (src/app/ui-module/)

This is where all of the UI related Angular components of the application live. The components in this module are broken up into two types:

Container Components

File Extension: *.container.*
Container components are used to separate UI related code from the NGXS code. Containers use selectors to obtain Observable state from the store, and disptach actions to the store to alert the application to user events.
Containers can created many view components in their HTML template.

View Components

File Extension: *.component.*
View components create the UI layer of the application. They typically contain HTML and Angular elements in their HTML template, along with the occassional container component. Since these components create the UI layer, they are also styled via a bundled .less file.
View components are completely ignorant of NGXS, services, and GroupMe in general. They accept a variety of @Input() parameters, which they display and style, and emit a variety of @Output() events in response to user actions.

Network Modules

For lack of a better term I'm calling these network modules, as they are responsible for communicating with GroupMe and storing the resulting information in the NGXS store, either by way of HTTP requests or websocket messages. These modules are largely organized based on GroupMe's API endpoint organization, which is why the Like Message Module is its own separate module and not bundled with the rest of the messaging functionality; this was an odd design decision on GroupMe's part but to each their own I guess...

General Organization

Network modules are further organized in to a collection of sub-folders:

Services

The services directory contains any HTTP services that are needed to fetch data for this module. The network modules in Cat Chat (with the exception of the web-socket-module) are organized around the GroupMe API endpoints that they interact with:

• group-chats-module: https://api.groupme.com/v3/groups/
• like-message-module: https://api.groupme.com/v3/messages/
• user-module: https://api.groupme.com/v3/users/

The services defined for a given network module are responsible for contacting all of the URLs for their module's GroupMe endpoint and returning the resulting responses. Bundled with each service is another directory labeled models. The models directory contains a collection of JSON objects, defining the required request parameters for each of the service's methods. When another class wants to call one of the service's methods, it will first construct the corresponding request object which it will then pass to the service object when it calls the method.

Store

The store directory contains the NGXS *.state.ts file for the parent module, along with any selectors defined for that NGXS state object.

The *.state.ts file both defines the state object model as well as all action handlers that are allowed to modify that state object model. This is handy as all of the code that can modify this state is consolidated into a single file. Additionally, we get to decide at the state-level which actions we want to listen to. We can choose to ignore actions that should not have any impact on this state object.

The *.selectors.ts file defines all of the NGXS selectors for the state object model mentioned in the paragraph above. Since there can sometimes be a lot of selectors for a given state object, we separate them out into their own file just to keep things well organized and files from becoming huge. These selectors allow components throughout the application to obtain Observable slices of our state object. We can define selectors that filter and/or organize our state slice differently than how it is represented in the state object model, saving us from potentially having to define multiple models for the same set of data.

Actions

The actions directory contains the NGXS actions files for any classes that emit actions within this module. In the network modules, these actions primarily correspond to success / failure events emitted in response to the service's HTTP calls. Here is a typical sequence of events:

1. Some component, we'll call comp, emits an action, comp-action
2. Our state class, state has an action handler for comp-action, which needs to fetch some data from the server to update the values in state
3. state constructs the required request model object for the method of the HTTP service, serv, that it wants to call
4. state calls the method on serv, passing in the request object
5. serv makes the HTTP request, which either succeeds (returns response object) or fails (throws error)
6. If the serv method returns the response successfully, state emits the success action for that serv method call
7. If the serv method throws an error, state emits the failure action for that serv method call
8. state updates by handling the success / failure actions emitted in (6) and (7)

Group Chats Module (/src/app/group-chats-module/)

Like Message Module (/src/app/like-message-module/)

User Module (/src/app/user-module/)

Web Socket Module (/src/app/web-socket-module/)