-
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
Feedback #15
Comments
Hi @tomdavies - thank you for this!
This is indeed an interesting idea and not one I'd really considered so far in the development of this prototype. I'd need to have a bit more of a think about it but I have to say my gut feeing is that it comes with a few difficulties, mostly that:
Neither of these concerns are insurmountable and I'd definitely like to explore this idea a bit further - I've opened issue #21 to track any discussion/progress on this topic.
This is very true... however I guess the flip side is that it is probably still easier than
Yup! Added issue #17 to track the implementation of this.
Yeah this has a lot of potential I think. I've started playing around with a JSON-schema plugin (because the existing tooling around that format is pretty good) in the feature/plugin-json-schema branch and I'm quite excited about seeing where it goes. If you have any more thoughts about any of this stuff let me know and thanks again! 👍 |
Hi @allmarkedup thanks for the considered reply, will post a few bits on #21 and will be following your json schema branch with interest. |
Hi Mark,
Really like the way Fractalite is shaping up. I work with @samuelgoddard so not going to repeat everything he said in #3, as I essentially agree with him. I do have a couple of specific FRs for consideration though (see below)
Initial thoughts
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?
Yes
Components
v1-style 'single file components' are no longer supported. Does that pose any difficulties for you?
Not for us, we always used the directory-per-component approach previously anyway.
Do you have any thoughts on the naming of configuration properties?
(For example, v1 'variants' and 'context data' config properties have been renamed to 'scenarios' and 'props' respectively. Are those names better/worse/the same?)
Adapters
Which template engines/frameworks would you most like to see integration with? (2 - 3 max)
For developers...
Are there customisations that you'd like to make that you think might not be possible in the current plugin system implementation?
The current plugin implementation works really well for extending Fractal to present additional information.
It also might be interesting to consider if there's merit in a standard pattern for plugins to feed data back into a running Fractal server instance. This could be pretty simple, e.g. allowing plugins to register for a hook, and then providing an endpoint that accepts (say) something like a component handle, a plugin handle and an arbitrary payload that is received by the plugin fn registered to the hook.
A couple of example workflows that I can think of that could make use of something like this:
Design review Our design team will often use our Fractal instances to design review components while they're in dev. It would be great to be able to update component metadata / config to store data about that process in the component's config file, e.g. storing a timestamp or updating component status after a designer has hit a "complete review" button in the fractal UI.
In-browser prop editor. Being able to fiddle about with prop values live in the browser a la Storybook Knobs would be great, but to get it working for SSR templates like Twig you would need a way to tell Fractal to re-render a given component with a revises set of prop values. See also my FR for typed props or similar below.
To be clear, I'm suggesting Fractalite should just provide the hook for plugins to register on and endpoint to invoke the hook, and leave everything else to plugins.
Do you think the monorepo approach is a good route future Fractal development?
Personally I find it way easer to work with. I guess one thing to have regard to is keeping the overall bar to participation in the project low enough to encourage the widest range of useful contributions. A monorepo makes sense to me personally but might be confusing to devs that aren't familiar with lerna etc. This is probably just something that we can solve with docco tho.
Other
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)?
1.Component statuses. May be on your list already (as it's in 1.x) but can't currently see it in the roadmap, so adding here.
Being able to set statuses per component is super useful. We do a lot of work where we're handling front end to back end teams, using Fractal our single source of truth for components, so being able to clearly label what's ready / WIP / deprecated is great.
Could be a plugin easily enough I guess, but I think there's a strong argument for putting them in core.
The text was updated successfully, but these errors were encountered: