Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a feature flag to select the desired UI design #1814

Merged
merged 8 commits into from
Jun 24, 2020
Merged

Conversation

andresmgot
Copy link
Contributor

@andresmgot andresmgot commented Jun 23, 2020

Description of the change

The goal of this PR is to conditionally load the required CSS for hex or for clarity based on a feature flag. Thanks to React.Suspense and React.lazy we are able to dynamically load components. The goal of the CSSSelector component is to load either the HEx or Clarity components that loads the CSS file.

Applicable issues

Additional info

This PR is based on #1813, there are ton of minor style changes due to the changes there (and master). @absoludity can you enable the pre-commit hook so those changes are attached to your PRs in the future?

Base automatically changed from 1762-set-state-from-config to master June 24, 2020 03:23
@absoludity
Copy link
Contributor

absoludity commented Jun 24, 2020

This PR is based on #1813, there are ton of minor style changes due to the changes there (and master). @absoludity can you enable the pre-commit hook so those changes are attached to your PRs in the future?

If code should not land without matching a certain style, then it should fail to be approved (by CI). A pre-commit hook isn't what we want, imo (and in my specific case, I don't even have node installed on my system at all - I run all frontend tests and code in a container when needed which is pretty simple and nicer, imo).

What I've don in other projects is to run required formatting checks on the code in CI, and if there are any changes after running, fail. Are you OK with that instead? That forces people (like myself) to follow any requirements without assumptions about where or how it is run.

Let me know when you've rebased (gh already changed the base branch when I landed mine) and I'll review :)

@andresmgot
Copy link
Contributor Author

I run all frontend tests and code in a container when needed which is pretty simple and nicer, imo

I disagree but that's a personal opinion. Even if you write unit tests to ensure that whatever you are implementing works as expected you will need to check if everything works end-to-end (also I usually discover issues even if they are not related to the new code). Building the dashboard image is quite slow, if you are working in cosmetic changes (CSS) I would say that's not even an option. Once you have the setup ready, it's quite easy to run the dashboard locally and changes are reflected instantaneously.

What I've don in other projects is to run required formatting checks on the code in CI, and if there are any changes after running, fail. Are you OK with that instead? That forces people (like myself) to follow any requirements without assumptions about where or how it is run.

Yes, that's fine as well.

Let me know when you've rebased (gh already changed the base branch when I landed mine) and I'll review :)

will do 👍

@andresmgot
Copy link
Contributor Author

@absoludity this should be ready to be reviewed now

Copy link
Contributor

@absoludity absoludity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

@@ -70,6 +68,7 @@ class Header extends React.Component<IHeaderProps, IHeaderState> {
const reposPath = `/config/ns/${cluster.currentNamespace}/repos`;
return (
<section className="gradient-135-brand type-color-reverse type-color-reverse-anchor-reset">
<UISelector UI={featureFlags.ui} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me here - does this actually make a selector appear in the UI? I assume not since we've got a feature flag to select which UI... so what does this component do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I called this "selector" because the component is in charge of selecting the css file to load (but maybe another name is more suitable?). The selection is made automatically based on the configuration so the user just sees the configured UI. You will see an example in the next PR.

@@ -0,0 +1,17 @@
import * as React from "react";

const HEx = React.lazy(() => import("./HEx"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it matches the filename, but was that a typo? (the 'E' rather than 'e')

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, the design system is called "HEx": https://design.bitnami.com/

@andresmgot andresmgot mentioned this pull request Jun 24, 2020
@absoludity
Copy link
Contributor

I disagree but that's a personal opinion. Even if you write unit tests to ensure that whatever you are implementing works as expected you will need to check if everything works end-to-end (also I usually discover issues even if they are not related to the new code).

Yes - of course, I usually do an IRL check once the changes are done, but it forces me to plan the change and write the failing test, fix, next test, fix, etc., and only when I think the required changes are done, build the image and verify it works as expected... obviously sometimes I then find issues and go back to reproduce with a new failing test and fix etc. Yes, I could still do this without having to build the image at the end which would be slightly faster.

Building the dashboard image is quite slow, if you are working in cosmetic changes (CSS) I would say that's not even an option.

Yes - it's very useful for cosmetic changes. I've not done (and don't often do) large style changes, but I'd definitely use it for that.

Once you have the setup ready, it's quite easy to run the dashboard locally and changes are reflected instantaneously.

Yep, I'll go back and try again to see if I can get it working within a container and if not, install it locally (I'd just prefer to have things like this running in a container where possible).

@andresmgot andresmgot merged commit 2728548 into master Jun 24, 2020
@andresmgot andresmgot deleted the uiSelector branch June 24, 2020 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants