Add logic for v1.0

[mykyta-shulipa]

No styles yet
ref #1

[mykyta-shulipa]

[OleksiyRudenko]

v1.2 (#3) is to introduce jsx and also end up with component props handling.
For illustrative purposes we'd need to have at least one parametrized component before <Component prop="val" /> syntax gets introduced.
That's what parametrization of UnitSwitch component might look like: 736a0b8
I could implement it as a part of transition from v1.1 to v1.2, or we might introduce this type of pain in v1.0 already.
What do you think?

[OleksiyRudenko]

P.S. My proposal is to have dev branch as a target branch for merges, keeping main codeless until lectures are delivered one by one.

[OleksiyRudenko]

• Changed target branch to dev
• Made UnitSwitch a weirdly parametrized component

[mykyta-shulipa]

@OleksiyRudenko

P.S. My proposal is to have dev branch as a target branch for merges, keeping main codeless until lectures are delivered one by one.

Any branch here is not hidden, so if we decide to hide code from students:) we could consider work in some other repository and push here (or work here and push to another one).
But having main branch clean is a good idea anyway 👍

[mykyta-shulipa]

@OleksiyRudenko LGTM.
Do you think we could merge this and continue working on v1.0 scope (styles etc.) in upcoming PRs?

[OleksiyRudenko]

@nktssh basically, we can.
Merging of the changes from #12 and pushing dev to a new divergence point will cause non-crtitical conflicts (package config). We can resolve those in this PR (following the proposal below) or later on, locally, or at any further PR review stage.

The proposed plan:

1. Squash-merge Add boilerplate #12 into/onto main once changes get approved (this would become a starting point for the students)
2. Rebase dev onto main
3. Resolve conflicts in this PR (package* will cause conflicts)
4. Merge this PR into dev

Once the above done the further development is conflict-safe