(feat) Architecture on top of Reveal

[nilscognite]

Type of change

Jira ticket 📘

https://cognitedata.atlassian.net/browse/

Description 📝

Overview of the proposed architecture her:
https://docs.google.com/presentation/d/1Y50PeqoCS5BdWyDqRNNazeISy1SYTcx4QDcjeMKIm78/edit?usp=sharing

There will also be documentation in the Readme.md file: src\architecture\base\README.md (WORK ON THIS NOW)

Link here: https://github.com/cognitedata/reveal/blob/np/actitecture-in-reactcomponent/react-components/src/architecture/base/README.md

How has this been tested? 🔍

yarn
yarn build
yarn storybook

This will goto: https://localhost:3000/?modelUrl=primitives
Open Architecture/Main
The toolbar to the right hand side contains all new functionality

Checklist ☑️

• I am proud of this feature.
• I have performed a self-review of my own code.
• I have added PR type (Feat, Bug, Chore, Test, Docs, Style, Refactor) to the PR title.
• I have manually tested this for different scenarios (different models, formats, devices, browsers).
• I have commented my code in hard-to-understand areas.
• I have made corresponding changes to the public documentation.
• I have added unit and visuals tests to prove that my feature works to the best of my ability.
• I have refactored the code for readability to the best of my ability.
• I have checked that my changes do not introduce regressions in the public documentation.
• I have outlined any known defects / lacking capabilities in the contents of this PR.
• I have listed any remaining work that should follow this PR in the description or jira/miro/etc.
• I have added TSDoc to any public facing changes.
• I have added "developer documentation" in any package README.md that is related / applicable to this PR.
• I have noted down and am currently tracking any technical debt introduced in this PR.
• I have thoroughly thought about the architecture of this implementation.
• I have asked peers to test this feature.

[haakonflatval-cognite]

I believe this contribution will be a major cornerstone in future development, and I'm conceptually very happy about it. There are some conventions/code style choices that disrupt our current norms, but I think we should wait until we've gotten our hands wet in testing it out before addressing it and coming up with better suggestions. I'll note some of my immediate concerns here:

• The current setup treats constructions as multiple-statement processes, so that e.g. constructing a domain object often looks like this:

const object = new DerivedDomainObject();
object.field = value;
....

I'd rather put such field initializations into the constructor itself

• Users are expected to inherit from e.g. Domain objects to integrate with the architecture, and there is in general heavy emphasis on class hierarchies and inheretance throughout the architecture. Obviously, it will work, but I do wonder if we can get away with something more "Typescript-y". It also means that many fields (name, color etc.) will be present in all Domain Objects even though they may not be relevant for all (at least unless we have a 2D three-view of the DomainObject hierarchy, of which there has been some talk. I believe @christjt had some ideas around this involving composition. I'll allow him to describe his ideas himself when he's back

[haakonflatval-cognite]

LGTM-ish 👍