Open petermuessig opened 2 years ago
@marianfoo @marcelschork FYI
@vobu - feel free to join the discussion
This new approach wouldn't render old custom libs useless nor break them. It's just a better approach which makes custom controls integration smoothier and fixes some of the current problems, most notorious being: multiple versions and extra configuration.
Another benefit: it opens the door for people start experimenting with ES modules.
The problem for individual deployment could be solved deploying a custom component wrapping the custom pkgs one uses.
Also, this would finally enable a much easier integration with storybooks 😍
Already expected in: https://github.com/ui5-community/ui5-cc-chart/issues/4
@mauriciolauffer - thanks for joining the discussion and your feedback.
Rgd. storybook -> I will continue my experiments over the weekend. Last weekend I already got a UI5 Button running - but to support it properly, with JS/XML code, a plugin needs to be written. I found one https://github.com/leon-vg/storybook-ui5/ but this is also a very basic one. I wanted to understand the possibilities of writing a storybook plugin better. It would be really cool to just use it on top of any library or custom control project.
Rgd. pros/cons: one thing I see a bit negative with the pure NPM package approach is that you can't hide the folder structure of the repository. Typically, you organize your project in folders src
, lib
, whatever and via the NPM package this immediately becomes visible for the consumers. There is the possibility defining main
modules which are loaded when requiring just the module but in case of hosting different UI5 Controls this is not useful. There the shimming approach is even a bit better as you can hide those internals. Anyways, in the NPM community, this is a well know practice to refer to modules in the repos folder structure... 😄
Storybook
I've done some work inspired by storybook-ui5, but making it more similar to @storybook/html and cleaned up a little bit (for the sake of maintainability). I've removed some of the overhead (using react to create root elements) and made it work with ui5 objects as well, eg, new sap.m.Button(), it was working only with xml string.
Have a look at my forked branch: https://github.com/mauriciolauffer/storybook-ui5/tree/feat-ui5-obj
The most important file in the project is app/ui5/src/client/preview/render.ts, everything else is just boilerplate.
An example on how to consume it can be found in examples/ui5-kitchen-sink.
$ npm run package:build
$ npm run storybook
PS: after we run some tests and make more changes, I'm going to create a PR with our changes in storybook-ui5.
just chiming in with .02€, admitting that I've only heard from storybook through here. But I'm intrigued as it seems a viable way of prototyping UI5-based UIs, with BUILD being gone. Thanks for shedding some light into this, guys!
Storybooks aren't meant to prototype UIs, as BUILD was. It's a automated testing tool for UI components, actions, visual regression, etc.
For instance, you could use it to test your ui5 control accessibility, visual regression (the button colour/font/etc looks different after a change)...
Where it could overlap with BUILD is the ability to deploy the storybooks as an standalone webapp and share with your team to gather feedback. However, you don't have the option to drag&drop UI elements to build a whole app.
For custom control packages namespaces and package name both are valid but package name has the following pros and cons:
Pros:
Cons: