Frontend standardisation

[mpetrunic]

• Add Frontend page here with following subject:
  • recommended project structure (maybe starter repo)
  • different IDE configuration and useful plugins
  • linter configuration
  • recommended and vetted libraries to use
  • testing - what libraries to use for mocking and some examples
  • CI setup
  • Chainsafe's Component library

---

Migrated from notion:

Brainstorm

• https://docs.ckan.org/en/ckan-2.7.3/contributing/css.html
• https://google.github.io/styleguide/htmlcssguide.html#CSS_Style_Rules
• http://getbem.com/introduction/
• https://www.freecodecamp.org/news/css-naming-conventions-that-will-save-you-hours-of-debugging-35cea737d849/
• https://www.sassmeister.com/gist/fe753a8228da9ed45136
• https://github.com/stubbornella/oocss/wiki
• https://cssguidelin.es/

https://mui.com/

💡 All timelines will be divided and sorted by newest on top

---

On Friday, November 5, We had a discussion about $Component Library Implementation$ which opened a few new questions.

• Common project architecture
• Common Company tools
• Chainsafe's Component library
  • Use case for the library?
  • How is gonna be used?
  • Implementations...

My recommendation is to contain 2 separate meetings between the architecture and component library.
(please comment if you agree or disagree about this)

cc @BeroBurny @sweetpea22 @FSM1 @Tbaut @RyRy79261 and others who I forgot to tag

[BeroBurny]

Personally don't like the idea of having MUI skin as a component library.

---

About CSS, we tried (@irubido and me) to use the BEM bus is more confusing but dint does not work well with component hierarchy.
For other methodologies, we dint dive enough to find a good way to use it in our architecture.

---

Architecture
Think we can go to 2 approaches it depends on the project scale.
For small scale projects, they should have folders inside src something like this

• assets
• components
• containers
• pages
• services
• styles
• ducks
• hooks
• types
• utils

A bigger project should be split into chunks inside the pages folder to represent the routes hierarchy
for example

• pages (is root page)
  • index.tsx
  • trades
    • components
    • containers
    • assets
    • index.tsx
    • history
      • index.tsx
      • User.tsx

where subfolders are only relevant for specific routes and root-level are used for globally shared code.

---

Recommender libs

• classnames - simple utility but pretty useful tool for manipulating className's

• axios - defacto standard for HTTP requests

• date-fns - date manipulation library

• react-router-dom - routing library

• formik - extremely useful for big form

• joi - validating object/form

• redux - global state managment tool

  • @reduxjs/toolkit - simplifies life of writing redux loop
  • redux-saga - powerful data flow managment

[ivanceras]

Hi guys, apology if I'm pushing my personal project.

I have created a front-end framework which is inspired by elm (The Elm Architecture).
The name of the project is sauron.

It has demonstrated that is a viable alternative to other front-end.
Here is an example code on how to use it as front-end for a Near contract.

This project is certainly a niche, which is targeting rust developers who are trying to use rust for front-end development. Most rust programmers are in the back-end side of things.

The advantage of using sauron is that I am the core developer and adding support for case where it is not supported can be added as we go along.

[wainola]

Personally don't like the idea of having MUI skin as a component library.

About CSS, we tried (@irubido and me) to use the BEM bus is more confusing but dint does not work well with component hierarchy. For other methodologies, we dint dive enough to find a good way to use it in our architecture.

Architecture Think we can go to 2 approaches it depends on the project scale. For small scale projects, they should have folders inside src something like this

• assets
• components
• containers
• pages
• services
• styles
• ducks
• hooks
• types
• utils

A bigger project should be split into chunks inside the pages folder to represent the routes hierarchy for example

• pages (is root page)

  • index.tsx

  • trades

    • components

    • containers

    • assets

    • index.tsx

    • history

      • index.tsx
      • User.tsx

where subfolders are only relevant for specific routes and root-level are used for globally shared code.

Recommender libs

• classnames - simple utility but pretty useful tool for manipulating className's

• axios - defacto standard for HTTP requests

• date-fns - date manipulation library

• react-router-dom - routing library

• formik - extremely useful for big form

• joi - validating object/form

• redux - global state managment tool

  • @reduxjs/toolkit - simplifies life of writing redux loop
  • redux-saga - powerful data flow managment

We had a meeting with @FSM1 about this, so we can figure it out a way to organize this. I guess it would be great to organize a guild meeting to talk about this. Our general considerations are the following:

• We shouldn't enforce a strict organization for the projects. I think we can have some consensus over this or even create (or update) a boilerplate for the projects. There is this one that we can use. Also I think that folder structure would depend on the requirements of our projects. Because if for some reason there is a need to use SSR for one project, and we pick NextJS as our choice, folder structure is going to differ for a simple create react app (@BeroBurny address this referring to bigger projects). In any cases we should discuss this.
• We also discussed about library usage. We think it depends of the scope of the project. There are some projects that don't rely at all in making request to some services, so having axios would just add up to the bundle size. Form libraries and validators we think could be problematic to enforce. Some developers are more use to one or another, or just to make their own validations. State managment is a big topic in frontend, but in general those libraries are too opinionated and with a lot of ceremony. Personally I would leave this to the judgment of the team.
• About contributing to this wiki, with Michael agree on writing about testing. @FSM1 have experiencie with Cypress and, in the current project that I'm working on we are going to have funcional test over our bridge methods, so I can contribute on that part.
• CSS: this is controversial. On this I think it would make sense to enforce some standard. Personally I have use styled components and JSS. I don't have a particular strong opinion about this. Also it depends if we are going to agree in the usage of some library for our frontend components.

[mpetrunic]

@wainola Just a note for library usage, I didn't mean that you write here libraries that each project must include.
But rather to have something like:

• for calling HTTP API use "axios"
• for testing use "cypress"

But for certain we should standardize directory naming across organisation so it's easier to onboard and guide new developers as well as make it easy for people to switch between projects. Obviously some project will have additional directories and that's ok.

I'm thinking of creating github repo for standards (similar to https://github.com/ipfs/eslint-config-ipfs) which we can push to npm so for lining instead of copying configuration, you could do in .eslint.json

extends: "@chainsafe/standard"