Fractal: Create plugin interface for handling of configuration files

[allmarkedup]

Would be really nice to have plugins that can add extra functionality via additional elements in the configuration files - for instance add a schema for context data that can then be build on in the web UI.

Some thoughts:

• If implemented, existing config file handling should be ported to use the same plugin structure
• How are these plugins registered? What format do they take?
• How is functionality that they provide exposed on each object via the API?
• Can/should they be able to provide accompanying UI within the web interface in a theme-agnostic manner?
• What precedence do plugins take if more than one is set up to use the same config data? Piped from one to another or overidden?

[micahgodbolt]

I'd love to be able to write a plugin that created a new tab for editing the current data context, like my schema editor tab at http://patternkit.info/schema/quote.

This tab would include a form defined by a JSON schema, and would include the current context data by default. Changing the form data would create an ajax request back to the server asking for new markup, based on the modified data.

JSON Schema supports WAY more than just simple variables as well. It allows you to define required fields, collections of fields (as objects) and even lists of fields or collections.

[allmarkedup]

Hopefully the plugin system I'm envisaging will let functionality this be added. However there is one potential issue with the dynamic server-side rendering which is that it wouldn't work for static HTML builds, so this sort of functionality would have to be excluded. The alternative (supporting client-side rendering) would be theoretically do-able but would require quite a bit of work to get it to match the server-side logic.

Excluding specific functionality from the static build would be pretty straightforward, but up until now I've been very focussed on trying to get the static builds to match the functionality of the dev server. _However_ for something like this it would be a shame to not have it in the dev server just because it can't be implemented in the build, so it would probably be justified, as long as it was highlighted clearly enough in any docs.

[paulrobertlloyd]

Can/should they be able to provide accompanying UI within the web interface in a theme-agnostic manner?

Off the top of my head, I can envisage a few ‘blessed’ points in the UI where plugins could be allowed to hook their UI functionality into:

• Tabs: Ability add tabs to the details panel view. I imagine the content of a panel would be left entirely to the plugin, with any visual inconsistencies left to one side. Alternatively, Fractal would need to provide some sort of mini-framework for composing panel views, but this is probably too restrictive. Perhaps better for Fractal to have some example plugins whose quality in this respect sets the bar.
• Sidebar: Ability to add new top level section types in addition to components, docs and assets. Should additions like this be tied to the creation of new types under the hood, or would more flexibility be allowed?
• Header: Ability to add buttons (to the right?) to activate a particular feature. What about dropdown switchers? Again, how much freedom would developers have in adding custom UI. I think the same liberal approach as for the tabs example probably applies, but without any overriding guidelines, multiple plugins could cause issues.

Thinking to my SassDoc plugin example, I may also want to expose my output in multiple places; a link under the documents type header, and/or component specific output in a tab.

[samuells]

@allmarkedup @paulrobertlloyd Guys did you considered some frontend frameworks like Vue.js, React & Angular? I would love to find out more, what it will be need to implemented such functionality using the Vue.js and it should work also on static pages, if we do it per page app as SPA? What do you think. And the bonus of instant variable update will be great!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.