web5.md

Okay, this is where I leave you.

Improvements

Infinite Scroll

We have a few issues with our current Infinite Scroll:

1. It will attach infinite elements into the DOM as is being scrolled;
2. The code for handling it is being copy/pasted in different files to do the same thing;
3. Some files has extra handling for no apparent reason;

How to (possibly) solve these issues:

• We can create a hooks and have all the logic there for handling this scrolling behaviour and use it everywhere;
• Create a new component (name suggestion: <VirtualInfiniteScroll />) that is the offspring of merging react-infinite-scroll and react-virtualized.

What to expect from this solution:

• Faster application with no scroll lagging;
• Reduce around 150 lines of code in around 12 different files;
• The code will be smaller and easier to read and maintain;
• Main logic would be concentraded in two files: useInfiniteScroll and VirtualInfiniteScroll

State management

Nowadays we have two folders that contains the state management code: actions and reducers. It would be nice if we had all the state management logic separated in a more modular way.

How to (possibly) solve these issues:

• We could have a new structure like the one below:

- redux
  - auth
    - actions.ts
    - constants.ts
    - reducers.ts
    - selectors.ts
    - index.ts
  - chat
    - actions.ts
    - constants.ts
    - reducers.ts
    - selectors.ts
    - index.ts
  - ...

Move/Remove files and code

There are a bunch of file we'll never use in the project. Having them is a complete waste of memory and time. We also have multiple files that has logic/code duplication and the only thing different between them is the name.

How to (possibly) solve these issues:

• Check every single file (starting with /models folder) and delete everything that is not being used;
• Check the /helpers folder and group/ungroup files and functions (how? read line below);
• Rename files/functions to better express what they do;

What to expect from this solution:

• Searching files will make more sense and it will be faster;
• The only thing needed in order to use a function or a file will be read its name;

Code share with good description

Since our application tries to reuse most of the functions and hooks its produce, it would be nice if we had good names for the functions as so as good descriptions for all of them.

How to (possibly) solve these issues:

• Rename functions to better express what they do;
• Use a comment structure like the template below (based: https://devhints.io/jsdoc):

/**
 *  @deprecated since...
 *  @description Remove the duplicates from an array
 *  @param {any[]} array - Any array
 *  @returns {any[]} array with unique items
 *
 *  @example
 *
 *    arrayUnique([1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6])
 *    // [1, 2, 3, 4, 5, 6]
 */

What to expect from this solution:

• Cleaner way to use functions;
• Small example to easily see if function can be used to solve current problem;
• Types and small description on when this function can be useful.

Broadcaster and Viewer pages

These are probably the most complex pages we have. Both can sum up to 3k lines of code down their own index.tsx files, not mentioning the other specific components they need in order to work. They are very confusing at first and hard to maintain.

How to (possibly) solve these issues:

• Create a hooks for handling toasters;
• Create folders like Viewer/Header, Viewer/Content, Viewer/Message with a single index with all the logic there and export these files to be used either on Viewer or Broadcaster page;
• ...

Double check available HOCs

We have a few HOC (Higher Order Components) spread in the application. Most of them could become simple functions or, at least, being more used and taken advantage of.

How to (possibly) solve these issues:

• Centralize HOCs in specific folders to make them easily spotted;
• Verify its functionalities and decide if they need refactoring or could be converted to simple functions;
• Kill the ones that give us little advantages
• Keep and maintain the ones that give us solutions;

What to expect from this solution:

• Reduce code complexity;
• Have robust HOCs;
• Let us focus on other problems apart from what they do;
• Reduce the amount of code spread in the application;

Hooks vs HOCs

... placeholder...

New folder structure

- src
  - components
    - Button
      - _styles.scss
      - index.tsx
    - Avatar
      - _styles.scss
      - index.tsx
    - ...
  - configs
    - whitelabel
      - streamago
        - development
          - siteconfig.ts
        - production
          - siteconfig.ts
      - dogpound
        - development
          - siteconfig.ts
        - production
          - siteconfig.ts
      - siteconfig.default.ts
    - siteconfig.descriptor.ts
  - data
    - apis
      - payout
        - payout.ts
        - wages.ts
        - schema.ts
        - index.ts
    - models
      - user
        - currentuser.ts
        - index.ts
  - domains
    - Stream
      - Viewer
      - Broadcaster
    - Post
      - List
      - View
        - _styles.scss
        - index.tsx
      - index.ts
    - Profile
    - ...
  - helpers
    - arrays.ts
    - delay.ts // throttle, debounce, ...
    - devices.ts 
    - event.ts
    - file.ts
    - ...
  - hooks
    - useInfiniteScroll
      - index.ts
    - useWait
      - index.ts
    - ...
  - redux
    - middlewares
    - post
      - actions.ts
      - reducers.ts
      - selectors.ts
    - wallet
      - actions.ts
      - reducers.ts
      - selectors.ts
    - store.ts
    - index.ts
  - styles
    - functions
    - mixins
    - skins // old schemes folder
      - dogpound
        - skin.scss
      - streamago
        - skin.scss
    - _app.scss
    - ...

Split and reuse siteconfig.json

We have a bunch of siteconfig.json inside /configs. It would be nice to have a way to encapsulate these information on specific files and reuse them accross the app. On first attempt, there was a browser error saying that require is not a function. This was due to the fact that webpack was not parsing and working on whitelabel siteconfig files. In order to fix it, it is necessary changes on webpack.config.base.js to make it work.

After updating the webpack.config.base.js, we could have the following structure:

• /configs/siteconfig.ts containing configuration interfaces;
• /configs/siteconfig.common.ts containing the common code used accross al lthe whitelabels;
• /configs/whitelabel/siteconfig.facebook.ts containing facebook credentials and object configuration generation;
• /config/whitelabel/*/siteconfig.ts exports a config object based on siteconfig.common and siteconfig.facebook.

c'est tres bon