For the last few months, we’ve been hard at work on the next version of Fractal.
In response to feedback from Fractal users we’d pinpointed some key areas of improvement, and after exploring many different options, we realised that in order to accomplish all our goals we’d need to make some significant changes to the architecture. Essentially, we’re splitting Fractal into four separate parts. I’ll give a detailed explanation of the problems encountered and decisions made to arrive at this solution, but in brief, the new areas are as follows:
Why?
Hopefully, the benefits of this approach will be immediately obvious, but if not, here’s how we reached this conclusion.
We began by looking at common feature requests and challenges that users had raised.
For example, if you want to share information about your pattern library with different teams or departments, you ought to be able to only include the information relevant to that team or department, and display it in a way that is useful to them. However, either sharing a link to a Fractal component library or running a build to produce documentation currently displays components in only one way, and includes all the information contained in the pattern library. Documentation produced this way may then be either excessive or unhelpfully formatted for its intended recipient, which will work against collaboration, implementation, and reuse.
Conversely, as a developer creating components, you don’t really need to review every aspect of the documentation whenever you view a component, nor do you want to have to consider the details of how a component might be previewed; you just want a preview of each component with its resources bundled and applied properly so you can test and tweak it. Everything you can accomplish as a developer must still work when static documentation is generated, meaning that most dynamic functionality is severely restricted. Clearly, requiring the same User Interface (UI) for both documentation and development limits the flexibility of what both can do.
After some time spent analysing these problems, we realised that they were all related to one central issue. It was clear that two separate concerns were entangled in the current Fractal implementation: development, and output. As a result, we decided to split these apart. Having a common core referenced by both aspects, and a CLI to provide access to functionality, followed naturally from this. Thus arose:
The Fractal Quaternity
As the name indicates, there are four main aspects:
The core parser
The core parser is what looks at your filesystem and determines what the components are and how they relate to each other. It uses a plugin based system, so adding new functionality (such as component ‘tags’) is as easy as adding a new plugin. Its only responsibility is to generate component specifications from the filesystem and an API to interact with that specification data. A ‘specification’ consists of information that fundamentally defines a component such as its contents and file path, and anything your plugins might have added.
The static site generator
The static site generator uses the data created by the core parser and combines it with templates you create, to render static pages in whatever style, combination, or format takes your fancy. This gives you complete control over the layout and structure. Creating output such as documentation, a static site, or even a pdf, is its sole concern.
The web-based development tool
The web-based development tool or ‘devtool’ also uses the data created by the core parser, but instead its responsibility is to generate previews of all your components, including all of their variants and custom data. This will enable developers to preview, test and iterate quickly during the development phase of a component without having to worry about details of how documentation regarding implementation and usage might be generated. It will also enable designers to be involved at an earlier stage of the component development process.
The CLI
This will build on the existing implementation and extend its functionality to complement the new structure.
Other improvements
We’re also working on many other changes to improve Fractal’s usefulness and flexibility that aren’t directly tied to the change in architecture. The core parser now handles multiple template files for a single component, so that you can easily have versions in each templating language you might require. We’re also introducing optional ‘schemas’ to help you define your component’s data structure. This will enable validation and automatic generation of context. The plugin system will ensure that new features, rendering methods, and custom functionality are simple to add. We’re really excited about the direction this new release of Fractal is taking. We aim to ship the first iteration of the parser, with some core functionality, by the end of the week but we’ve still got a lot of work ahead of us. We’ve begun active development of the static site generator, and the devtool is in very early prototype stages. Join us on the Fractal slack channel to give feedback on this developer release and help shape Fractal’s future!
