3.0.3 • Published 2 years ago

@equinor/smart-portal v3.0.3

Weekly downloads
-
License
MIT
Repository
github
Last release
2 years ago

Build Build and Publish E2E BrowserStack Status Snyk

Smart Portal

Smart Portal is a digital operations manual intended for offshore activities. This package is developed as an external module to be run under the EchopediaWeb monorepo.

First time development setup

https://github.com/equinor/smart-portal 1. Clone the repo 2. npm install 3. npm run predev -> get your self-signed certificates 4. npm start -> a webpack dev server instance is available at https://localhost:3000

Local development with EchopediaWeb

In order to test Smart Portal running locally under EchopediaWeb, a soft-link between the repos can be created with yalc. 1. (in Smart-Portal) npm run build 2. (in Smart-Portal) npx yalc publish 3. (in EchopediaWeb) npx yalc add @equinor/smart-portal 4. (in EchopediaWeb) npm install 5. (in EchopediaWeb) npm start 6. (in Smart-Portal) make your changes then npm run build && npx yalc push

EchopediaWeb dev server will recompile and you changes should be reflected in the browser.

Coding rules

  • Strive for clean code (and what to look for in code reviews/PRs)
    • Use well defined function/variable names. (A well defined name is much better than comments, which often quickly get outdated/obsolete)
    • Function names should tell what a function does. Bad: OnClick()/HandleOnClick() Good: OpenTag()
    • Avoid negative names. Good: IsActive IsEnabled. Bad IsInActive/IsDeactivated IsDisabled. If(IsEnabled) is eaier to read than if(!isDisabled) <- (double not)
    • Single Responsibility - A Function/Class should only do one thing. Split into sub functions.
    • Use PURE functions to Avoid hidden side effects. It also makes it a lot easier to add Unit Tests
    • Avoid Code smells like: Code duplication, Long method, Long class, Long parameter list. etc
    • No Magic numbers or strings! Bad: const time = 600000; Good: const millisecondsInTenMinutes = 10 60 1000;
    • Write code in a way that the compiler finds the BUGS! Avoid ANY. Define variables as optional/nullable in interfaces.
    • Try to split UI and Logic in different files. Ideally the UI shouldn't contain any logic. Logic also wants to get unit tested.
    • Favor functional programming over imperative programming: Use map, filter, find, etc instead of loops/ifs
    • Prefer immutable objects/interfaces
    • Avoid premature optimization - benchmark first.
    • Prefer undefined over null
  • Fix all eslint warnings and errors in your files.
  • Always checkin the code in better shape than you found it, fix/cleanup smaller things as you edit a file.

Testing

Comes soon

VS Code Extensions

Must-have

  • ESLint
  • Prettier

Suggested

  • GitHub Pull Requests
  • Import Cost
  • SVG
  • Version Lens
  • Todo Tree
3.0.3

2 years ago

3.0.2

2 years ago

3.0.1

2 years ago

3.0.0

2 years ago

2.2.9

2 years ago

2.2.7

2 years ago

2.2.8

2 years ago

1.0.0

2 years ago

1.0.0-rc1

2 years ago

1.0.0-rc2

2 years ago

2.0.0-rc.1

2 years ago

2.2.1

2 years ago

2.2.0

2 years ago

2.2.3

2 years ago

2.2.2

2 years ago

2.2.4

2 years ago

2.1.0

2 years ago

0.9.1

2 years ago

0.9.0

2 years ago

0.8.1

2 years ago

0.6.3

3 years ago

0.8.0

2 years ago

0.8.3

2 years ago

0.7.0

2 years ago

0.6.2

3 years ago

0.6.1

3 years ago

0.6.0

3 years ago

0.5.5

3 years ago

0.5.4

3 years ago

0.5.3

3 years ago

0.5.2

3 years ago

0.5.1

3 years ago

0.5.0

3 years ago

0.2.10

3 years ago

0.1.10

3 years ago

0.1.8

3 years ago

0.1.9

3 years ago

0.1.5

3 years ago

0.1.4

3 years ago

0.1.3

3 years ago

0.1.2

3 years ago

0.1.1

3 years ago

0.1.0

3 years ago