How to handle modular / conditional rendering across node types

[Cstrachan4]

Hi there,

Currently trying to migrate an existing site to Vizy from the standard craft matrix block. In our current implementation we have fields that are consistent across some block types, but not all. For instance some blocks allow users to decide the column span of the content via a field and others have a predetermined span based on the design.

The current templates check if the field exists and then if it does, applies a class to the container so it spans the selected number of columns.

With the craft matrix block it seems each block has all fields from each block type available in the data structure and when they don't exist the value is set to null, which allows this type of conditional rendering. However when checking if a field exists via Vizy it throws a "Calling unknown method" error if its not available for that block type.

Wondering if theres anyway to achieve a similar modular approach to fields with Vizy to avoid having to do a big refactor of everything?

Thanks in advance!

[engram-design]

So Matrix blocks will work a little differently, because they have their own content table, which is for the field. Each blocktype field will generate its own column in the Matrix field content table, so you can technically access fields from another blocktype. But I think that's pretty risky behaviour (I haven't confirmed if you can do this, but I wouldn't have though you could access fields from another blocktype).

I think, if it were me - rather than leaving it up to chance by whether the field exists for the blocktype or not, I would add guards (even for Matrix) to check on the blocktype first. It's more work, but at least I would consider that a "correct" implementation.

You can certainly forego this if you like, by using something like a null coalescing operator.

{{ vizyBlock.someNonExistantField ?? null }}

Which would not throw an error if that doesn't exist. But if you were to share a snippet of your template, I can make get some more context on the specifics?

[Cstrachan4]

Hey, thanks for the response!

Yeah thats my understanding of how it works too. Sure, makes sense as to why its different here.

Ultimately thats what I've ended up doing, but feels a little less flexible than the previous approach – although agree its on the safer/more correct side as you mention.

So heres a snippet from the template rendering the blocks/nodes:

{% for block in entry.blocks.all() %}
    {% set isBlock = block.type == 'vizyBlock' %}
    {% embed '@components/entry/entry.twig' %}
      {% block body %}
        {% set type = isBlock ? block.blockType.handle : block.type %}
        {% embed '@components/block/block.twig'
          with {
            hasColumns: type
              in ['chart', 'image', 'bespokeChart', 'carousel'],
            hasTitle: type in ['chart', 'image', 'bespokeChart'],
            hasCaption: type in ['chart', 'image', 'bespokeChart']
          }
        %}
          {% block main %}
            {% include ['_blocks/' ~ type ~ '.twig', '_blocks/default'] %}
          {% endblock %}
        {% endembed %}
      {% endblock %}
   {% endembed %}
{% endfor %}

Then heres an example of the block component, the 'has' variables are what I've added to get around the error. Previously they just checked that block.fieldName existed / wasn't null.

<div class="block{{ hasColumns ? ' block--' ~ block.columnSpan }}">
  {% if hasTitle and block.itemTitle %}
    {% embed '@components/figure-title/figure-title.twig' %}
      {% block title %}
        {{ block.itemTitle }}
      {% endblock %}
    {% endembed %}
  {% endif %}

  <div class="block-item block-item--{{ type }}">
    {% block main %}
    {% endblock %}
  </div>

  {% if hasCaption and block.caption %}
    {% include '@components/caption/caption.twig' with {
      text: block.caption
    } %}
  {% endif %}
</div>

The operator you've sent is ideally what I'd like to set 'has' variables with on the block embed, but still throws a 'calling unknown method' error for me.

The above is fine and working now with the changes though, just means updating the 'type in' arrays when a block with the relevant field/s is added or removed. I guess thats the only thing I was trying to avoid, but obviously not a big issue!