Multiple template engines for components / preview templates (e.g. by file extension)

[jkphl]

I'm about connecting Fractal and TYPO3 (a PHP based CMS). While TYPO3 doesn't have a dedicated component concept, one can well organise his work appropriately and export component-like entities to Fractal. I'm using a custom Fractal CLI command for this, reading the components from a custom CLI interface to TYPO3 and setting up Fractal's component directory structure accordingly. (At the moment, both modules are proof of concept / work in progress so please excuse the lack of documentation etc.).

TYPO3 provides several different ways of rendering output which are likely to be used side by side. There's e.g. Fluid — a "real" templating engine — and also TypoScript, which is TYPO3's very own configuration syntax capable of creating output as well. They all have in common that they rely heavily on TYPO3 as rendering context (e.g. they might need to access the global TYPO3 configuration, use some of the many view helpers or rely on a HTTP request being made) so Fractal has to delegate component rendering back to TYPO3 as a "templating engine" (which I made already work for one of the component types).

However, calling TYPO3 is a comparably costly thing in terms of rendering time, so I would like to keep the calls down to a minimum — which makes me wish there was a way to register multiple rendering engines so that they could get picked e.g. by template file extension or component configuration. This seems related to what @paulrobertlloyd was calling for in #26. It would be super nice to be able to

• use e.g. Handlebars for the preview layout (which is simple enough) but use something different for the component itself,
• use different templating engines for different component types.

Please let me know what you think or if there's something I could contribute!

[allmarkedup]

@jkphl yes a few people have asked for this and it would be great, but unfortunately would actually be very tricky (impossible?) to implement with the current model of filesystem parsing that Fractal uses. That parser is due for a major re-write at some point in the near-future however, and part of that work will include adding support for being able to register multiple component-format renderers.

Very cool to see the stuff you are doing here though and once I get started on the new parser implementation it would be really great to get your feedback on whether it would help address your requirements.

[jkphl]

@allmarkedup Alright, I see. I will try to work around this restriction for the time being, but it would be really nice to see it working anytime soon. I'm planning to spend some fulltime days on my open-source projects between Christmas and New Year, so maybe I'll try to come up with something for Fractal. My biggest obstacle will probably be that I'm not too familiar with ES6 syntax & features so far though, ha! Will be a good lesson for me ...

Happy to give you feedback once you're on to it. Keep up the good work, it's really inspiring! :)

[DanielRuf]

Wouldn't shelljs, Fluid standalone and so on work as a solution to utilise Fluid in Node based projects?

[jkphl]

@DanielRuf For "just" rendering Fluid templates this would surely do it. But there's a lot more to be considered when building a component library for a TYPO3 project. What about TypoScript components, exbase controller actions and so on? I made it work, but still, being able to use multiple templating engines in Fractal would be very nice.

[DanielRuf]

@jkphl personally your solution with the bridge, the PHP classes and much more work feels a bit much for me as frontend developer.

Don't misunderstand me but generally it makes more sense to mock most of these things and just render the needed Fluid. At least we just work with Fluid and VHS in the frontend. I would like to see the concerns more separated (pure frontend with Fluid templates generated from the components and backend components) and not so strict integrated into TYPO3.

Like already mentioned, multiple renderers for the different template languages / multiple engines and an abstraction level (JSX) which can generate the needed (Fluid) markup based on some render mode and uses atoms with the original markup (in Fluid).

I'm not sure how the patternlab twig engine generates the markup but something similar could be needed for Fluid.

Just my opinion about this.

[jkphl]

@DanielRuf I guess we both have a very different approach on this. I understand your concerns, but in fact this doesn't match our daily work situation at all. We don't foster sharply outlined professions like "frontend developer" and at least here in our team there's no such process as "just mocking out something" that's going to be used by somebody else with real data later on. Your approach might work as long as you only use Fluid templates — but as you know, there are other ways of generating HTML from TYPO3 as well. These can't get covered by a simple template engine and you can't just abstract them away without reproducing large parts of TYPO3 (you wouldn't want to do that either).

More importantly though, we don't just use our component libraries as means of developing the frontend part of things. They became an indispensable tool for all project stages and participants (and their respective roles — clients, conceptionists, designers, frontend and backend developers). We want our component libraries to be truly "living" — also and especially after a project has launched (think of long-term documentation) — so this is why we prefer "real" data and a true live connection between the component library and our production code. As long as this doesn't hinder the development process — and at least for us it doesn't — I cannot see any disadvantages. I understand that this might expect too much of other teams and constellations and they'd probably want to go down the road you describe. I'm fine with that. ;)

[DanielRuf]

Well, Patternlab also isn't like this. You are right, your approach is different than ours and I prefer decoupled solutions wich work without a live setup behind it but can be always connected to one and so can the data come from everywhere.

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

[neezer]

@allmarkedup Is this more possible now, with the current state of Fractal? I have a similar need.

This wishful API in fractal.config.js sums it up:

fractal.components.engines([
  { ext: ".jsx", engine: createReactAdapter(/* ... */) },
  { ext: ".hbs", engine: createHandlebarsAdapter(/* ... */) },
]);

I can easily configure Fractal for one of those at a time, but not both. 😢