I've been playing around with the Angular support branch contributed here.
After building this in a fork and consuming it in a sample Angular CLI app, it looks the Storybook Deployer/ compiled static assets break when deploying to gh-pages.
Test repo:
https://github.com/priley86/storybook-ng-wc-demo
Error thrown here upon compilation w/ Storybook deployer inside Webpack module/static output:
https://github.com/priley86/storybook-ng-wc-demo/blob/master/storybook-static/static/preview.30bc209875689e205495.bundle.js#L28972
throw new Error("Module parse failed: /Users/priley/GitHub/storybook-ng-wc-demo/node_modules/@storybook/angular/dist/client/preview/angular/index.ts Unexpected character '@' (24:2)\nYou may need an appropriate loader to handle this file type.\n| \n| const getAnnotatedComponent = (meta, component) => {\n| @Component(meta)\n| class NewComponent extends component {}\n| ");
Deployed ng storybook w/ error:
https://rawgit.com/priley86/storybook-ng-wc-demo/view-storybook/index.html
Appears the Angular preview source here is getting referenced in the static build incorrectly (should be only be used in local/node js runs I'm guessing).
Great job with this and look forward to having this formally released w/ the Storybook family. I'll be doing some research w/ Web Components/Skate.js alongside Angular & React implementations inside Storybook, and hopefully I'll be able to share some of this after!
cc @alterx
@alterx, another observation here after playing some more w/ Custom Elements & ng in my fork...we'll need a way to provide schemas to the NgModule being used to render the stories. Given the current examples/documentation, I didn't see a good way to do this. I've changed the default module in my fork to include CUSTOM_ELEMENTS_SCHEMA, but I'm sure we can find a more flexible way to do this...
https://github.com/priley86/storybook-angular/blob/master/dist/client/preview/angular/index.ts#L42
@alterx @ndelangen @shilman any ideas? I'm happy to take a stab at this if given direction... would especially like to have the Storybook Deployer working for ng in my fork...
@priley86, yeah, this is the kind of feedback we need. This is still a WIP (currently finishing the last part of it) and I'd like to stabilize the features a bit before starting to play around with new things (such as Web Components). There's also a big effort to refactor out the core parts of the app that are currently duplicated for each supported framework.
Regarding the deployer, I haven't even look at that one :(
If I were you, I'd wait a bit before digging a lot into this :)
How experienced are you @priley86? Any chance to get you to help @alterx to get the angular feature out faster?
Sounds like you already got things running and are a fantastic help testing the feature!
I'm not trying to pressure either of you btw!
@alterx I will be monitoring your feature branch closely and providing the best feedback I can. If you're making significant refactors, I will happily hold off for now 馃槈
@ndelangen I work on Red Hat's User Experience Design team (we do all of the designs for Red Hat's core products along with maintaining the open source library used in these products, Patternfly). We've already adopted Storybooks in our Patternfly React repo and are looking to expand this to our Patternfly Ng/Angular and Patternfly Web Components repos in the future. I will definitely be staying tuned and trying to submit feedback as best I can! I'll also be interested in enhancing addons where possible. Look forward to your progress on this one w/ @alterx and please keep us posted. 馃樃
hi @alterx @ndelangen just following up here...
I've continued testing #1474 and shared this with our Angular team @ RedHat. I'm happy to report the following:
I've deployed a sample Storybook from my testbed here:
https://rawgit.com/priley86/patternfly-webcomponents-next/ng-storybook/index.html
https://github.com/priley86/patternfly-webcomponents-next
Our team is very excited about the progress here, but would like a few more features before we can officially adopt Storybook for Ng.
Thanks for all the great work here! I'm OK with closing this issue if we'd like to repurpose it (as my original requests were met) ...
Glad to hear that @priley86. Modules are definitely something in my list but we wanted to focus on getting it to work first 馃槃
There are some implications about letting it (potentially) render a full application, for example: how do we handle the case in which we send a module with several components? How do we decide which props apply to which component. We need to define an API for that and we would love your feedback.
@alterx I think our use case is possibly more simple that what you have in mind. We develop example components/modules which import the component's module (like the one here). This just basically ensures that downstream consumers can import the same module which defines this component (and that we are emulating this).
@alterx so i agree that those complications can arise if trying to target multiple components/multiple modules, but I think as a short term suggestion, I'd just ensure that imports and schemas can be extended for the current component/current module being displayed, possibly as arguments to the stories function?
storiesOf('Welcome', module, imports, schemas)
I would not try and target additional modules/additional components, just the current ones like you have now... and just adding the additional imports/additional schemas...
This would get us there I am thinking...but any flexible way you can come with, I am happy :)
i.e the current code supports single component with no dependent modules...so i've just used simple inheritance on my example component (inheriting from the actual component) as a short term workaround.
It would be ideal for us though to be able to define an additional imports on the module being demo'd (and leave any concerns arising from that to the consumer...
Story now:
story -> example module -> example component -> (inherits) consumable component
Story proposed:
story -> example module -> example component module (renders consumable component) -> (imports) consumable module -> (imports) consumable component
Hope this describes our use case better...
Hey @priley86 Can you tell us if things have changed now that the angular work has been merged into the release/3.3 branch?
You can expect an official alpha release real soon! /cc @shilman
@ndelangen apologies for the late response... it's been a hectic few weeks. I don't think we will be exploring custom elements/web components for a while (it's a bit too early for us and we are currently progressing w/ React & Ng only).
Last I checked, the storybook-deployer was working fine w/ 3.3 branch and Ng. The main issue w/ Web Components was the current WC polyfills have some es6 in their distribution which breaks when included w/ the current version of uglify. I had a workaround in my fork for this...
https://github.com/priley86/storybook-angular-demo
https://github.com/priley86/storybook-angular
Looks like you are leaving uglify soon enough - so that should help...
I had proposed one other feature recently in Storybook Deployer. Not sure if you are filtering these ;)
Will report back as we progress...
Can we make a copy of https://github.com/storybooks/babel-plugin-react-docgen for typedoc?
Guys @ndelangen , @priley86 , is there's still anything actionable to do here?
I'm going to close this one as it seems the original bug is no longer happening and it's been stale for more than a month.
Most helpful comment
Hey @priley86 Can you tell us if things have changed now that the angular work has been merged into the release/3.3 branch?
You can expect an official alpha release real soon! /cc @shilman