Hi Lee,

No, I've not tried anything yet. I'm still at the "thinking about it" phase.

One idea I had been pondering (not in great detail) is to try to recreate, more or less, what Fractal does in Umbraco as a sort of starter kit, using views and partials for the components and combining them into modules using compositions. The already modular nature of Umbraco seems like it would suit the problem. At it's core, Fractal is a bunch of view templates with some data to populate the templates (context data), which maps quite nicely to the concepts of MVC models, views and partials. But then Fractal does some other nice things such as per-component configuration, variants and some stuff with naming conventions. So I dunno, it's a thorny problem. I'm not sure how important that extra stuff is, or how difficult it would be to output the raw code contained in the views to the frontend.

There's a Fractal Slack group and it would be worth asking what other teams are doing on there, I reckon. One interesting approach from Brad Frost is outlined in this article.

I'm going to the Patterns Day conference in Brighton at the end of June. I'll hopefully come away with some useful knowledge and inspiration. I'll report back here with what I come away with. :)

Thanks Charles. It's gonna be an interesting process, for sure.

With the Fractal implementation that I'll be working on, I asked if they could use the Handlebars one, (they'd originally suggested Vash; although it's based on Razor syntax, it's definitely not Razor).

My thought is that I could use the Handlebars.Net view-engine and attempt to use Fractal directly. Obviously this creates its own restrictions, but we'll see how this pans out. I'll let you know how it goes.

I wanted to go to the Patterns Day conf, but the date ended up clashing with something else. I'd be interested to know your thoughts on it, etc.

Cheers,
- Lee

Thanks Lee, it'll definitely be interesting to see how it goes. Have you taken a look at the API? It looks like the whole question of integrating with production code is still being worked out.

Given the general interest in component libraries, perhaps your experiences would make a good article for Skrift or 24 Days?

Thanks Dave. I've had a look at Pattern Lab, too. I like the disco mode. :)

It would be really interesting to learn more about the nuts of bolts of your approach. Are you able to share any more detail? Perhaps it's worth an article?

Would love to see a skrift article on that topic. We have been looking at patternlab the last few years, but have been reluctant to use it out of fear of not maintaining it in the future.

Hi Brian,

I'm neck-deep on my current project with integrating Umbraco & Fractal, it's going pretty well.

I have a proof-of-concept working, pulling content from Umbraco, building a view-model (in JSON) and passing it to the templates (in my case Handlebars).

It's quite interesting in that you have to give up total control of the frontend over to the pattern/component library. In one respect, it makes total sense; in another, after years of ad-hoc hacking in Razor, it's weird giving up control of that.

I'll aim to blog about it once I'm happier with the process - like I say, it's still very much a proof-of-concept for my current project.

In terms of templating, I'm using a library called Chevron to render Handlebars - it is literally using the handlebars.js library with a .NET JS Engine (you can pick from ClearScript.V8, Jint or MSIE). I'm currently using MSIE, due to quirks in Jint (and ClearScript.V8 has weird assembly lookup issues). All good fun!

Cheers,
- Lee

Hi Lee,

Really looking forward to it. As Patternlab also uses handlebars I could use a similar approach.

Dave

So, an update on my progress. I have a fully functional website, fit for purpose.

Although I'm not happy with the rendering performance, but that's an implementation detail, which currently output-caching is hiding well.

Conceptually the idea works...

1. Front-end developer can works on the component/pattern library in isolation.
2. View-models are defined in the component templates
   • They typically use JSON - as majority of libraries are node/JS driven.
3. A component map is exported from the library.
   • This is the vaguest part. I'm using Fractal, a la this blog post that Charles referenced above.
   • I'm still experimenting with this part. Since I'm using Handlebars, I'm looking at precompiling all the templates, for performance gains.
4. Templates are exported from the library. To be copied over to Umbraco website.
5. JSON data of the view-models is exported. To be (somehow) imported as C# POCO classes.
   • I'm currently using Visual Studio's "Paste Special > Paste JSON as Classes" feature. There may be ways to auto-magic this?

Then it's a case of mapping Umbraco data to the desired POCO.

Since I develop on the Ditto mapping library, that's my tool of choice... other mapping libraries are available, choose your own poison.

Since my POCOs will map 1-to-1 with a Fractal component, I decorate the POCOs with a custom attribute that will help me bridge the link between the Fractal component and the Umbraco doc-type... something like this:

[FractalComponent("@someComponent", "someDocTypeAlias")]
public class SomeComponent
{
    public string someHeading { get; set; }
    public string someContent { get; set; }
}

Then I've got some resolver code for Ditto to build the components up, (depending on how we've build the content in Umbraco - Nested Content / Stacked Content / Grid + DTGE). Ultimately do whatever you need to do to construct your POCO.

Once we have the POCO, serialize it to JSON and pass it to your view-engine....

Now, the topic of view-engines!!!

I've been around in circles with this. I've gone from trying to find a suitable Handlebars .NET library, to using a wrapper for a JS engine (Chevron) - currently switched back to using ClearScript V8, to trying out Edge.js ... I'm still not too happy with this part either.

The end goal is to get your JSONified view-model data over to component template, take the resulting HTML and server it to the browser. (A common-sense concept, right?)

Now, the complicated bits... navigation, forms, yadda yadda.

For navigation, I've been handling this within the controller, once we have the POCO (for the navigation/header part), I'll loop over the various items in the POCO and set whatever needs to be set to make navs items active/current, etc. Although it feels expensive to code, it's actually pretty quick to process.

For forms, this the tricky part... as my experience with forms on websites has differed for each and every website implementation I have done. There never seems to be a standard way. So at the moment I'd taken a cowboy approach, rendered out the form fields, set up a Web API controller to receive the POST data and then do whatever we need to do with it, (dump to database, email someone, etc).

I'd looked at doing an UmbracoForms to Ditto type of mapping, but I ran out of time - looming deadlines. But that could be something to explore.

So far, there has been a lot of trial and error... like I said to Brian on Twitter, "It's definitely not for the faint of heart, requires a bit of gusto."

I'll see how the QA (and client acceptance) phases of my project goes, and look to write up a more detailed way of doing this.

Hope some of this helps satisfy an itch :-)

Cheers,
- Lee

Hi Lee

How did it go with the project? Got any other insights to share? :)

We are giving it a whack on our next project, and anything useful would be appreciated!

Regards,

Brian

Hi Brian,

The project went well, the workflow between design & dev worked out well too.

The main downside we experienced is with our implementation - rendering JS in .NET hasn't performed as well as I'd hoped. But I expect this is open to vast improvements. We've ended up caching the hell out of our pages.

Overall it was a fun and interesting experiment! Although I'm not 100% convinced that I'd use the same approach on the next project, I think you need to have a good team on both front-end and back-end sides - who really understand the concepts involved. IMHO, from my experience many design agencies are a long way behind in this mindset.

You'd mentioned Pattern Lab previously - are you planning to use it for your project? I'd be interested in hearing how that goes.

Sorry I don't have all the answers, it still feels relatively new ground, there's a lot of trial & error :-)

Cheers,
- Lee

Thanks for the info! I was working with Pattern Lab and Drupal which was working fine since they both use Twig. There were the same mindset learning curve that you mention, but caching was not a problem since Twig is part of the core. There were of course also some challenges with forms. :)

I prefer Fractal because of the flexibility (sorry Brad & co), so I don't think we will be trying out Pattern Lab, also the next Fractal version is in beta.

I agree on your comment with design agencies, maybe we need more Frontend Designers (http://bradfrost.com/blog/post/frontend-design/)? :D

I'll try and write something when we have had the chance to give it a go ourself.

Regards,

Brian

Quick follow up on this - I've been experimenting with precompiling the Handlebars templates and it's reduced the runtime page rendering by x4 (from 400ms to 100ms).

The JS v8 engine evaluation code takes around 35ms. I'm still figuring out bottlenecks in other parts of our codebase, but good news is that I'm more optimistic about this now :-)