-
Notifications
You must be signed in to change notification settings - Fork 685
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
Bugfix/fixing storybook venia ui #1945
Bugfix/fixing storybook venia ui #1945
Conversation
|
@LucasCalazans Thank you for working on this abstraction. It's very well thought out; however, I'm not sure we want to add another layer of default Webpack config beyond I don't really have a problem with implicit Maybe I'm forgetting something that @supernova-at could remind me of; this bug is pretty old, so maybe it's more complicated than that. |
Yes!!! Thank you so much for this. Taking a look now. |
Agreed, let's try importing it manually. I'd love to get |
@zetlen I see. I was thinking about an application that just uses the But yeah, sorry about the delay in the answer, I'm working in a new version based on the venia-concept dev dependency. I'll try to push a commit today |
@supernova-at Just to be clear, do you think that we should import the webpack dependencies in the venia-ui or import the venia-concept's |
…lazans/pwa-studio into bugfix/fixing-storybook-venia-ui
Hey guys, I've tried importing the It's now getting some errors in the new Image stories. I've debugged and it seems to be a problem with some params that were not passed into the Image component like the |
I think this is great - definitely love moving the
I "fixed it" by updating the root If you can figure out why it's building Storybook instead of running it, I'd prefer that. I can verify that Storybook starts up without error, even though many of the stories are broken. |
Also I see |
* Returns the value of the first variable in any section whose name matches the input. | ||
* @param {string} targetVariable - The name of the environment variable to find. | ||
*/ | ||
const getEnvironmentVariable = targetVariable => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you just use loadEnvironment
instead of this custom function? loadEnvironment
should be able to do exactly what this function is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, actually I'm not sure
I tried to use it but it seems to have a dependency exactly where I need, in the MAGENTO_BACKEND_URL, when I use loadEnvironment to get this variable it throws a exception:
ⓧ Missing required environment variables:
MAGENTO_BACKEND_URL: Connect to an instance of Magento 2.3 by specifying its public domain name. (eg. "https://master-7rqtwti-mfwmkrjfqvbjk.us-4.magentosite.cloud/")
I tried using this code:
const loadEnvironment = require('@magento/pwa-buildpack/lib/Utilities/loadEnvironment');
loadEnvironment('MAGENTO_BACKEND_URL')
Do you know why is this happening? Maybe I'm using it in a wrong way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this either. The function signature of loadEnvironment is
function loadEnvironment(dirOrEnv, logger = prettyLogger) {
so it doesn't look like it wants the name of the environment variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LucasCalazans check out other places where we use it. For example in create-custom-origin
:
const projectConfig = loadEnvironment(projectRoot);
if (projectConfig.error) {
failExpected(projectConfig.error);
}
const config = projectConfig.section('customOrigin');
// etc
You pass it a directory and it returns an object with props on it. I'm not sure how well it is documented unfortunately. It may take some experimenting.
@@ -75,6 +75,8 @@ | |||
"peerDependencies": { | |||
"@magento/babel-preset-peregrine": "~1.0.0", | |||
"@magento/peregrine": "~4.0.0", | |||
"@magento/pwa-buildpack": "~4.0.0", | |||
"@magento/venia-concept": "~4.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that peregrine
is used by venia-ui
is used by venia-concept
. This seems like a red flag to me? But maybe I'm misunderstanding peer deps :P
I think this, along with the imports of venia-concept
files in venia-ui
just seem like red flags to me in terms of where we are supposed to be keeping these things. Maybe in the future we will move the majority of the base config to the top-level and venia-concept
and venia-ui/storybook
can just import/use it.
TL;DR - I think I'm fine with this, just rambling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think for the storefront app that's correct. For Storybook we relaxed the rules a bit so we could run it easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's a tough call. I do think @sirugh has the right of it here.
It's true that venia-ui
components are hard to render without the glue that venia-concept
adds, so we need to get that glue from somewhere. But venia-ui
is built to be a dependency of venia-concept
, so I'd prefer that it didn't list venia-concept
as a dependency or import anything from it. Thinking about our various options here:
Option | Evaluation |
---|---|
Duplicate store.js , webpack.config.js , and index.css |
bad |
Move these files up to some shared package | bad |
Import these files from venia-concept |
not ideal |
Move venia-ui storybook stories into venia-concept |
okay? |
Overall, I would accept the approach in this PR because the work's been put in, it has value, and only the Storybook files are importing from venia-concept
. But eventually I want to remove the circular dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes. I have not tested the PR for functionality yet. Will that soon. From code POV, it is good.
@LucasCalazans Are you working on the last changes I requested? Just checking :) |
I have some ideas on how to improve this. I'll go ahead and make them, should be small changes. |
@@ -6,7 +6,7 @@ const { | |||
const baseWebpackConfig = require('@magento/venia-concept/webpack.config'); | |||
const { DefinePlugin, EnvironmentPlugin } = require('webpack'); | |||
|
|||
module.exports = async storybookBaseConfig => { | |||
module.exports = async ({ config: storybookBaseConfig }) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
o.o
Description
Venia UI was not able to execute Storybook (Probably since the separation with
venia-concept
) because it was depending on a lot of thevenia-concept
files.My solution was to split the main part of the
configureWebpack
data in thebase.webpack.config.js
file, with that we can import the same file/config into thevenia-concept
andvenia-ui
without duplicate the code.To do that I had to include
@magento/pwa-buildpack
as apeerDependency
ofvenia-ui
. Without that, we, probably, would have to import the webpack config manually.Related Issue
Closes #1577.
Acceptance
Verification Stakeholders
Specification
Verification Steps
yarn storybook:venia
OR
venia-ui
package folderyarn storybook
Checklist
Additional Information
I fixed some problems related to Context API (Some components are using) adding a storybook decorator. With that, we will no longer need to add the
Adapter
neither theAppContextProvider
.Problems
index.css
anymore so some parts are missing styles (Like the MiniCart component)cartTrigger
component is calling REST APIs without using the BACKEND_ENDPOINT, so the calls are been succeded.