allmarkedup
commented
5 years ago Hi @tomdavies - thank you for this!
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 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:
- Moving away from a read-only interaction with the filesystem opens up a whole lot more potential security vulnerabilities. I've called it 'dev' mode to try and emphasise that the live server instance should only really be used locally and the static build for hosting, but that may not always be desirable (or adhered to) and I'm a little nervous about someone accidentally exposing write access to their server!
- Writing to config files is tricky as they can come in multiple formats (YAML, JS, JSON etc) and trying to write back to an object exported by a CommonJS module is potentially a bit of a headache.
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.
A monorepo makes sense to me personally but might be confusing to devs that aren't familiar with lerna etc.
This is very true... however I guess the flip side is that it is probably still easier than npm linking existing v1 packages for development! Bit of a nightmare ;-) But totally agree that good docs around this part are essential to ensure we get a lot of contributions from a wide range of developers.
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.
Yup! Added issue #17 to track the implementation of this.
Typed props. I saw you mentioned JSON schema support in #3 as a potential plugin idea, so this is essentially a +1 for that or similar.
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! 👍
tomdavies
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.