Finalize Comment Template Properties

[Paul-Hebert]

The Comment pattern has a number of properties.

The primary property is an object matching a Timber Comment. In addition to that it exposes a few other properties:

• allow_replies: A boolean property that controls whether to show a reply button and form
• logged_in_user: user object
• log_out_url: URL used for log out link.
• source: An optional object containing a url and name for the comment source.
• demo_post_author: Whether the commenter is the author
• demo_cloud_four_member: Whether the commenter is a team member.

Right now there's no way to pass these properties down to child comments (replies).

I think most of these probably are fine to not pass down, but the last two (demo_post_author, demo_cloud_four_member) will need to be passed down. We should explore how we'll integrate these in Wordpress, rename the properties, and make any necessary changes to the patterns.

[Paul-Hebert]

Thinking through how to identify whether a comment author is the post author or a team member.

Authors

Checking whether they're the post author seems like it should be fairly simple. The Timber Comment object has an author property which is a Timber User object. We should be able to compare to the Post's Author (also a Timber User.)

I believe in the future we want the ability to support multiple authors... Timber Post's have an authors method, but it just returns void?? 🤔 Maybe it makes the most sense to not worry about multiple authors until we figure out how we're handling multiple authors in general?

Members

The current site does this: {% if comment.author.get_meta_field('c4-team-member') %}

That seems pretty straightforward. We've still got this ACF field in our functionality plugin, so it seems like we can continue with this approach. In the future we could also do something similar to handle alumni if we wanted to.

However... how does this work in JS land? Do we just stub out a fake get_meta_field method on the comment author for that documentation example?

But what if we want to use this pattern in some other non-Wordpress project... maybe I don't need to worry about that since the pattern already expects a Timber-style Comment Object?

Or maybe we implement two different options for checking for team members?

1. Use get_meta_field
2. Manually add an is_team_member flag on the comment author

[tylersticka]

These questions sort of speak to my gut feeling that the path to success for these templates is to embrace more blocks.

If we look at the role badge in the comment.twig template, it actually doesn't have much to do with the comment component. There are no c-comment classes, we just plop it right in a heading.

So if we did something like this:

{# In patterns #}

<h{{_heading_depth}} class="c-comment__heading">
  {% block heading %}
    {{comment.author.name|default('Firstname Lastname')}}
  {% endblock %}
</h{{_heading_depth}}>

Then there'd be nothing stopping an app from doing whatever they wanted from within their templates:

{# In WordPress/Timber partial #}

{% include '@cloudfour/components/comment/comment.twig' with {
  comment: comment,
  post: post
} only %}
  {% block heading %}
    {{parent()}}
    {% if comment.author is post.author %}
        <span class="u-hidden-visually">(Article</span>
        {% embed '@cloudfour/components/badge/badge.twig' with {
          label: 'Author',
          icon: 'pencil',
        } only %}
        {% endembed %}
        <span class="u-hidden-visually">)</span>
    {% endif %}
  {% endblock %}
{% endif %}

This could even extend to replies. It was convenient for me to pass a block of comments as replies, but maybe it would be better to just define a block for those replies so that the apps themselves could embed whatever recursive logic they need to without having to traverse a proprietary component API for doing so...

{# in theme, partials/comment.twig #}

{% include '@cloudfour/components/comment/comment.twig' with {
  comment: comment
} only %}
  {%- block replies -%}
    {% if comment.children %}
      {% for reply in comment.children %}
        {% include 'path/to/partials/comment.twig' with { 
          comment: reply,
          whatever: 'weneed' 
        } only %}
      {% endif %}
    {% endif %}
  {%- endblock -%}
{% endif %}

If I have any critique for my own work here, it's that I let my dummy data guide me down a property-centric rabbit hole, instead of opening up the component's content containers for easy manipulation by our theme or other projects. The comment component's primary focus should be display a comment, not managing recursive comment data, y'know?

But I could be wrong! Hard to be objective about one's own work.

[tylersticka]

Maybe it makes the most sense to not worry about multiple authors until we figure out how we're handling multiple authors in general?

Indeed!

[Paul-Hebert]

Just confirmed both of these approaches should work on the Wordpress side:

    {% if comment.author == post_author %}
      (Post Author)
    {% elseif comment.author.get_meta_field('c4-team-member') %}
      (C4 Team Member)
    {% endif %}

[Paul-Hebert]

Just saw your comments. Thinking through a block-based approach...

Heading Blocks

I think switching over to a block here makes a lot of sense. I'm conflicted on whether the whole heading content should be a block (like your example) or if we should just have the badged content be a block:

<h{{_heading_depth}} class="c-comment__heading">
    {{comment.author.name}}
    {% block author_meta %}{% endblock %}
</h{{_heading_depth}}>

Replies Blocks

I'm more conflicted on this one. I like the flexibility that blocks provide, but I like that our existing component enforces a good heading hierarchy by passing down a higher numbered heading to the child comments:

{% set _child_heading_depth = min(_section_heading_depth + 1, 6) %}

...

{% include '@cloudfour/components/comment/comment.twig' with {
  comment: child,
  heading_depth: _child_heading_depth,
} only %}

This could also be handled on the Wordpress site, but since this also needs to work with the section heading depth (the "Replies" heading) it's nice having the pattern handle all those relationships. I dunno, what do you think?

But I could be wrong! Hard to be objective about one's own work.

I feel that!

[Paul-Hebert]

Right now I'm leaning towards replacing the demo_post_author and demo_team_member properties with an author_meta property and then switching over to the Wordpress side to confirm the updated patterns work there.

[tylersticka]

FYI, you can use {{parent()}} to output the parent's default block content!

So instead of this:

{# partial.twig #}
<div>
  {% block before_content %}{# nothing #}{% endblock %}
  {% block content %}
    Hello world!
  {% endblock %}
  {% block after_content %}{# nothing #}{% endblock %}
</div>

{# template.twig #}
{% embed 'partial.twig' %}
  {% block before_content %}Hey, look!{% endblock %}
  {% block after_content %}Whoa, hey!{% endblock %}
{% endembed %}

It can be a bit cleaner to use parent():

{# partial.twig #}
<div>
  {% block content %}
    Hello world!
  {% endblock %}
</div>

{# template.twig #}
{% embed 'partial.twig' %}
  {% block content %}
    Hey, look! {{parent()}} Whoa, hey!
  {% endblock %}
{% endembed %}

[Paul-Hebert]

Oh neat! I had no idea