Building a no-code platform, continued...

I wrote an article recently that got a great response, especially given it was the very first article I'd posted on this forum, so thanks to those of you that gave it some appreciation! If you're coming to this article having not read it, I'd suggest you give it a skim-read for some context. I wanted to do a follow up article to coincide with the introduction of Yakety, a platform I built using the principles I'm about to cover.

The last article gave an explanation of how it's possible to use abstract, dynamic components to attach tangible components you have written to a page: dynamically. This article takes that one (small) step further by looking at the data side of things in a bit more detail.

I'll begin by reiterating that my central goal when developing this builder was to ruthlessly avoid something called coupling, everywhere and at all costs. For those of you unfamiliar with the concept of coupling, it's where you group data that doesn't really belong in the same group, usually out of convenience. This leads to the obvious problem of having to de-couple and extract data which, if you were to ignore the benefits of de-coupling, would lead to the dreaded spaghetti code and would require all sorts of "hacks" throughout your code. Not good. It's a well-known principle in programming that you avoid coupling where possible. I was intent on taking that to an extreme by de-coupling data that could arguably exist in the same group. You could say I was aggressively decoupling... Spoiler alert: The big problem you immediately encounter however is keeping a link between data that does eventually need to come together to produce meaning, keep that in mind.

I briefly discussed in the last article a pattern that I had decided upon using, where I make data extremely granular and highly specific, then pass it to the browser in a big batch, so that it is accessible from anywhere within my code. I had no real grasp of the end outcome, I just knew that if I stuck with this principle then I'd be much less likely to end up in a code cul-de-sac!

It's hard to pick a place to start in the code but I'll choose to run with how I store a page:

{
    "data": [
        "4af6738c-f7f3-11ea-adc1-0242ac120002"
    ],
    "blocks": [
        "4af6745e-f7f3-11ea-adc1-0242ac120002"
    ]
}

What you're looking at there is the definition of a page. The data key stores an array of references to top level components. The blocks key points to an array of all components that are required on the page. This was a key decision, I could have stored subcomponent references against their parent components, but that would have led to really messy code and given, as I discussed, my strategy is to make all components and data accessible anywhere, this would have been unnecessary. All the page needs to define is the data that is needed and the same goes for each component, it just requires references, a definition. So the page definition plays an important role in defining all the data that is required to render the page. There are convenient opportunities that arise here in caching, manipulating the order of references, switching out references with new references etc. etc. I'm not saying it's without issues but it's a pattern worth thinking about for sure.

Let's assume the data and blocks data is parsed (server-side) and that leads to fetching the data needed to render the page. The data might look like this:

{
   "type": "s-hero",
   "slug": "4af6738c-f7f3-11ea-adc1-0242ac120002",
   "data": [
      "4af6745e-f7f3-11ea-adc1-0242ac120002"
   ]
}

{
   "type": "s-title",
   "slug": "4af6745e-f7f3-11ea-adc1-0242ac120002",
   "title": "Hi"
}

As explained in the last article, all that will happen is the dynamic component will loop the data array in the page definition then, in a recursive manner, it will render a hero component that itself will loop its own "data" property. The data it needs however, is not present within the hero component definition. It is accessible however, it has been attached to the browser window, as have all the definitions required to render the page, so the component just reaches out for the data it needs using the reference, finds it references a title component and renders the title using the data definition.

Voilà.

Sure there's some overlap with the previous article here, but the key concept I'm highlighting is one of decoupling your data. You don't have to choose the method I've employed to the letter, it's something I've devised completely on my own so there could well be a much more intelligent way to achieve this outcome. However, if you choose not to decouple your data to this extent, then you are risking causing some real coding headaches further down the line in the development process. I've encountered quite a few landing page builders that have been developed by either one person or a small team (not that this mistake is limited to small outfits, not by a long stretch!) and you can see from the example landing pages they exhibit that they are extremely limited. You're really tied into a set of templates with a very rigid structure. That's a result of diving into coding, taking easy decisions without giving due thought to consequences that will arise and so on.

I'll stop there. I'll decouple this article from other related discussions I could have around this subject! I hope that wasn't too painful to digest and that you learnt something useful. If this proves useful for people I'll keep going.

Keep it real.

Matt

PS If you would like to learn more about Yakety or get involved in building the platform, then drop me an email: [e-mail], register on the site, find me on social media, there are lots of ways to get in touch and lots of development tasks to get stuck into for all levels of ability (and non-development tasks for that matter) so please share this with your friends!