-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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:
Yes that should definitely be implemented - I've added issue #9 to track progress on that suggestion.
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?
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.
Yes for sure. If not as part of the core then definitely as a plugin - I've added issue #10 to track this.
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.
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! |
@allmarkedup Thanks for the answers and the creation of the related issues, I think it's all clear for me now. |
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?
Adapters
Which template engines/frameworks would you most like to see integration with? (2 - 3 max)
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:
path
helper currently)Things I'd love to see happen in the future
global
to expose the bundle as UMD)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)?
Any other comments/suggestions/ideas?
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.
The text was updated successfully, but these errors were encountered: