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

Feedback #15

Open
2 of 11 tasks
tomdavies opened this issue Mar 13, 2019 · 2 comments
Open
2 of 11 tasks

Feedback #15

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

Comments

@tomdavies
Copy link
Member

tomdavies commented Mar 13, 2019

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?)

  • Props over config every time, that's how we internally talk about the context a component receives as a dev team anyway (though that could be because we do a lot of Vue stuff)
  • Scenarios over variants is more subjective. We've previously been using a BEM approach to which variants maps really nicely. But I'm actually coming round more to scenarios as being more flexible (esp with respect to just changing the content of a component rather than it's classes / markup pattern)

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...

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.

  1. Typed props. I saw you mentioned JSON schema support in Initial short term feedback #3 as a potential plugin idea, so this is essentially a +1 for that or similar. Some initial use cases I can think of:
  • Easier component tests!
  • Self documenting for back-end teams in terms of the contract the component expects when they're receiving components to integrate
  • Enabling a plugin for a Storybook Knobs style in-browser prop editor
@tomdavies tomdavies added the Feedback comments / constructive criticism / suggestions / ideas label Mar 13, 2019
@allmarkedup
Copy link
Member

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:

  1. 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!
  2. 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
Copy link
Member Author

tomdavies commented Mar 15, 2019

Hi @allmarkedup thanks for the considered reply, will post a few bits on #21 and will be following your json schema branch with interest.

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