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

1st feedback #4

Closed
2 of 11 tasks
LeBenLeBen opened this issue Mar 9, 2019 · 2 comments
Closed
2 of 11 tasks

1st feedback #4

LeBenLeBen opened this issue Mar 9, 2019 · 2 comments
Assignees
Labels
Feedback comments / constructive criticism / suggestions / ideas

Comments

@LeBenLeBen
Copy link
Member

LeBenLeBen commented Mar 9, 2019

Initial thoughts

Did you have any difficulties getting the prototype demo up and running?

Nope, all good so far.

Were your initial gut feelings about the prototype direction positive or negative?

Very positive!

Do you think this prototype represents a good development direction for the next version of Fractal?

I'm amazed by the amount of work done so far and the overall direction it takes. It brings a lot of tiny missing features on the UI while allowing deeper customization everywhere. I'm sure it will be very appreciated!

Components

Did you like the @name folder name convention for components?

Yes but I can live without it.

v1-style 'single file components' are no longer supported. Does that pose any difficulties for you?

No, I've almost always ended-up creating directories for all of them.

Do you have any thoughts on the naming of configuration properties?

  • “Props” is better and closer to what people are used to in React or Vue communities.
  • “Scenarios” is probably slightly better than ”Variants”

Adapters

Which template engines/frameworks would you most like to see integration with? (2 - 3 max)

  • DustJS
  • HAML
  • Handlebars
  • Marko
  • Mustache
  • Nunjucks
  • Pug
  • React
  • Twig
  • Vue
  • Other - please specify below

For developers...

Does the plugin model make sense to you? Any questions/queries about it?

The plugins system looks amazing; I can imagine a Vue plugin where you could use vue-docgen-api to read the Vue component and automatically document all the methods, props, etc. in a panel; just like Vue Styleguidist does.

Are there customisations that you'd like to make that you think might not be possible in the current plugin system implementation?

Not that I can think of right now.

Does the Adapter system implementation make sense you you?

Yep, nothing wrong I've seen so far.

Do you think the monorepo approach is a good route future Fractal development?

Hell yes!

Other

Changes & features I enjoy so far:

  • “Standard” configuration file that exports an object
  • The performance of the UI, it's super fast!
  • The search of course, a long-time awaited feature
  • The indication of the preview container dimensions (had to implement that manually on some projects already)
  • The way you define where components are, feels closer to what Styleguidist do for example, it will definitely help keeping components assets and styleguide-related files together.
  • Auto-rewrite of assets path (so many support request about the path helper currently)
  • Being able to link to other components/pages/…
  • Full navigation customization (we often want the display the Changelog and a link to the repository)
  • Granualar theme customization and not just a limited set of predefined colors, at the moment this requires quite some stuff to be done.
  • Assets bundler with auto-injection
  • The ability to customize where the notes comes from, a pretty often requested feature from the community
  • Fractal-owned Vue adapter

Things I'd love to see happen in the future

  • Being able to specify options to the assets bundler plugin (such as global to expose the bundle as UMD)
  • The ability to use multiple adapters in the same project

Is there anything missing from the prototype that currently exists in v1 and that you think should be part of the core of any future versions (i.e. not implemented as a plugin)?

  • Components tags? That could be helpful for the search.
  • "View" panel that displays the original template? It's often preferred to the HTML panel by our developers.

Any other comments/suggestions/ideas?

  • There's no more default variant/scenario, right?
  • It says preview markup/css/js can be customized globally or per-component. But what about collections? In the past I've usually had the default defined globally and then wanted variants for a whole collection (like "Example pages" where you want to remove the body padding for all components for example).

Finally a big thanks for everything you did so far! You can count me in to help you improve the theme/UI, write some docs and potentially create some plugins related to Vue.

@allmarkedup
Copy link
Member

Thanks again for this @LeBenLeBen, all very helpful and great to hear that you are generally liking what you see so far.

With regards to your specific points/questions:

Being able to specify options to the assets bundler plugin (such as global to expose the bundle as UMD)

Yes that should definitely be implemented - I've added issue #9 to track progress on that suggestion.

The ability to use multiple adapters in the same project

Ahh yes... this is one I've gone back-and-forth on myself :-) It's not actually difficult to implement (i have had a first-pass working previously); however it's challenging from a UI perspective and from my experiments can make things a lot more complex from a configuration perspective too. It opens up a lot of questions such as 'how do we include certain plugins only for specific template engines', 'how can we support different preview requirements for different engines' etc.

My gut feeling is that needing support multiple template engines is a bit of a niche use-case and it doesn't really justify the additional complexity that supporting it would likely bring. I also feel that if we do want to implement it, then it could be a feature for a later release rather than the next one.

It is possible to have different config files for different adapters in the current implementation, so you can switch between template engines/frameworks, just not view them in the same UI instance. Not really what you mean I know but perhaps not a bad halfway house for now?

Components tags? That could be helpful for the search.

The search currently supports 'aliases' which work a bit like tags (see the button config for an example). In fact a tags plugin would be a good one to implement, and that could in theory add any tags into the aliases config property (as well as doing other useful things with the tags).

But the search is really still up for grabs. If people have suggestions for UI/UX improvements (or implementation!) then I'm definitely up for iterating on it.

"View" panel that displays the original template? It's often preferred to the HTML panel by our developers.

Yes for sure. If not as part of the core then definitely as a plugin - I've added issue #10 to track this.

There's no more default variant/scenario, right?

Correct - there is just a component that can be rendered/previewed with a number of known, named sets of props (i.e. scenarios), but none of these are given privileged 'default' status any more.

It says preview markup/css/js can be customized globally or per-component. But what about collections? In the past I've usually had the default defined globally and then wanted variants for a whole collection (like "Example pages" where you want to remove the body padding for all components for example).

Yes I too do this kind of thing quite regularly but my feeling was that as this is something that could be implemented as quite a nice plugin, it should maybe not be a part of the core feature set. I've opened issue #11 to keep track of this - once implemented we can then make a decision about whether to include it in the 'default' set of plugins.

Hopefully all that makes sense and let me know if you have any more feedback later on down the line!

@LeBenLeBen
Copy link
Member Author

@allmarkedup Thanks for the answers and the creation of the related issues, I think it's all clear for me now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feedback comments / constructive criticism / suggestions / ideas
Projects
None yet
Development

No branches or pull requests

2 participants