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

Separate visualizations into their own package #4837

Merged
merged 21 commits into from
May 6, 2020
Merged

Conversation

gabrieldutra
Copy link
Member

@gabrieldutra gabrieldutra commented Apr 25, 2020

What type of PR is this? (check all applicable)

  • Other

Description

Separate visualizations into their own package

To-do list:

  • Choose components to be shared instead of copied
  • Remove p-r-5 from redash-visualizations/src/visualizations/table/utils.js
  • Remove visualizations dependencies from main package.json
  • Adapt main build scripts
    • Netlify
    • Circleci (50%)
    • Dev env
  • Fix jest tests

Related Tickets & Documents

--

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

--

Copy link
Member

@arikfr arikfr left a comment

Choose a reason for hiding this comment

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

See comments.

Also the folder in the repo, how about we name it viz-lib?

@@ -0,0 +1,77 @@
{
"name": "redash-visualizations",
Copy link
Member

Choose a reason for hiding this comment

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

Let's name it @redash/viz. I've added you to the redash org on npm, so you should be able to eventually push it there.

@@ -0,0 +1,77 @@
{
"name": "redash-visualizations",
"version": "1.0.0",
Copy link
Member

Choose a reason for hiding this comment

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

Let's start with version 0.1.0 and switch to 1.0 when the API is more stable.

@gabrieldutra gabrieldutra force-pushed the visualizations-package branch 4 times, most recently from cff5ec4 to fa0cfbc Compare April 26, 2020 17:35
@gabrieldutra gabrieldutra force-pushed the visualizations-package branch from fa0cfbc to 220ccad Compare April 26, 2020 17:37
@gabrieldutra gabrieldutra force-pushed the visualizations-package branch from 73307c4 to ed61df1 Compare April 28, 2020 13:28
@@ -70,7 +70,7 @@ describe("Visualizations -> Chart -> Editor -> Colors Settings", () => {
.simulate("click");
});

test("Sets custom color scheme", async done => {
test("Sets custom color scheme", done => {
Copy link
Member Author

Choose a reason for hiding this comment

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

Was this async important for something I'm missing? It was causing this test to fail removing it didn't cause any harm 🤷‍♂️
(Probably some babel setting missing for it to work, but it was way easier to just remove it)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think async is not needed here, so it's ok to remove. Return value is always ignored, and done is used for async tests

@gabrieldutra gabrieldutra force-pushed the visualizations-package branch from 7e5bd3d to b0fcfd7 Compare April 28, 2020 15:14
@@ -2,7 +2,8 @@ FROM node:12 as frontend-builder

WORKDIR /frontend
COPY package.json package-lock.json /frontend/
RUN npm ci
COPY viz-lib /frontend/viz-lib
RUN npm ci --unsafe-perm
Copy link
Member Author

Choose a reason for hiding this comment

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

This seems to be required to run the preinstall script (which installs viz-lib deps and build it) when we run the command as root user. An alternative is to switch the user to the redash one in this scope. I tried to switch to it for all commands, but didn't seem that quick. Another option is to switch to the user only while running this command.

Copy link
Member

Choose a reason for hiding this comment

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

but didn't seem that quick

in terms of effort required to make the switch?

Regardless, --unsafe-perm should be safe in the context of running inside a Docker container build...

Copy link
Member Author

@gabrieldutra gabrieldutra Apr 30, 2020

Choose a reason for hiding this comment

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

in terms of effort required to make the switch?

In terms of changes in that file, mostly needs to update chown/chmod permissions for that folder. As the --unsafe-perm seemed simpler, I wanted to show it as an option, but needed to confirm regarding safety. I actually didn't sit down and actually tried to change thos yesterday, but I did today and I could get it to work like this:

FROM node:12 as frontend-builder

RUN useradd --create-home redash

WORKDIR /frontend

COPY package.json package-lock.json webpack.config.js /frontend/
COPY viz-lib /frontend/viz-lib
COPY client /frontend/client

RUN chown -R redash /frontend
USER redash
RUN npm ci
RUN npm run build

(notice I changed the COPY order to run only one chown, not sure if there was a reason to have it after the npm ci command though)

Anyway, LMK which option you prefer.

Copy link
Member

Choose a reason for hiding this comment

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

(notice I changed the COPY order to run only one chown, not sure if there was a reason to have it after the npm ci command though)

The reason for the current order is to make sure that we don't have to reinstall if package.json/package-lock.json didn't change, as they change less frequently than the codebase.

Let's go with the unsafe option for now.

@gabrieldutra gabrieldutra marked this pull request as ready for review April 28, 2020 22:58
@daniellangnet
Copy link
Contributor

I'm intrigued by where this is going! 👍
Just curious what the bigger picture is here so that I can decide when it makes sense for me to update my KPI visualization branch?

@gabrieldutra
Copy link
Member Author

Hi @daniellangnet, the idea here is to have visualizations to stand on their own (not to be dependent on any other part of Redash), so they can be turned into a separate package. All the bigger changes for that to be possible were already delivered in past PRs, so this one is mostly a setup + move the visualizations folder. In any case, this is the last one that will have "more significant" changes on the codebase (although it just moves files and it should be an easy merge). The goal is to make it transparent to development flows, so ideally it shouldn't affect your work. Thanks for contributing and I'll give a quick check on your PR anyways. 🙂

@gabrieldutra
Copy link
Member Author

This PR changes in Brief for ones that will review it:

  • Create viz-lib package.json and set it up with webpack to generate UMD bundled redash-visualizations.js and babel to just transpile it for more specific usage (in Redash for ex). I wanted to offer a transpiled version with css files instead of less too, but that seemed too much hassle;
  • Copied all visualizations folder to the viz-lib one;
  • Dev environment runs babel:watch on the lib in the background;
  • Added a build step for visualizations as a preinstall script (seemed the simplest way to make it transparent, not to require extra commands on the flow we have today). Future alternatives include maybe move it to our own bin scripts.
  • Separated visualizations Jest tests. Those were easy because they are unit tests, for the Cypress ones it's a bit more complicated since they are Redash tests (and it does make sense to have Redash e2e tests for it), but eventually we can move the more "unitary" of them to be tested through Storybook or sth;
  • Deleted duplicated files, a few components are now imported from the viz lib, though there are some duplicated that I didn't find to make sense to locate on the lib (e.g: sanitize service, which is basically our settings over DOMPurify). LMK if you think other should be in the viz lib too.

@arikfr
Copy link
Member

arikfr commented May 5, 2020

Should we merge this now?

@arikfr arikfr merged commit fc246aa into master May 6, 2020
@arikfr
Copy link
Member

arikfr commented May 6, 2020

🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants