- Moved the various tabs on the draft view to their own views.
- Renames modes to views
- Started to group various aspects of the workbench state under
`_state` in the gist to prevent it from getting all mixed up
with the core settings.
- Updated events title to make it more clear not all events might
be present
- Removed valid state in measurements input since it was only
getting updated on keyboard input but now when preloading
measurements (which it does now)
These changes force webpack to load the local pacakges (like
patterns and so on) from source, rather than from a compiled bundle.
This means that the lab site will reload whenever one makes changes
to pattern code.
This is a replacement for the hack I implemented in
bb901c4d8a
It accomplishes the same effect, but with just setting the key prop.
Sadly, it does not work with just setting the key prop to the theme
but forcing the key prop to be re-set by including the date does the
trick.
To be clear: This is still a hack and I'd love to avoid it (or just
understand the right way to handle this) but for now it will do.
This is a workaround for the following problem that I can't seem
to understand.
This JSX code:
<p data-theme={props.app.theme}>{props.app.theme}</p>
Is rendered as:
<p data-theme="light">dark</p>
This happens only upon initial page load because on the server
side we don't know the user's preferred theme. So we start with
the default (light).
Then, as the app bootstraps in the browser, it updated the content
of the P tag with the new theme (dark).
However, for reasons that I really don't understand, it does not
update the `data-theme` attribute.
So this works around that be forcing a different component for each
theme that has the data-theme hardcoded. By force-rendering a different
component, we can be certain React has no choice be to re-render the
entire tag.
If anybody could explain to me why this happen, I'd gladly buy you
a coffee or something.
