INTERESTING THINGS

I, like many, have ideas for products we want to build, yet find it hard to get moving. 

For me, my latest idea has me actually moving forward with what I think is a good idea. 

Not an idea that will make millions of people happy, or buy into it, but a simple product that will help in an area that I do not see being utilized.

I have decided I am going to try and document my challenges, and journey a bit in writing.

Please join me on the journey to create Small Robot The Product.

Challenge 1 - API or Full Stack

Currently I have been using Drupal 8 as an API (JSON:API) up until now, but now I have concerns that a fully decoupled Drupal 8 will not scale as I want it to. I am constantly wondering if I should change the from the API / Front end app approach, to something like full stack Ruby on Rails, Phoenix, or Laravel. The reason the thought to change is there, is that I see products like Shopify, TransmissionFM, Basecamp, and others, that are successfully using Ruby on Rails, and in their cases, not running as an API + Front end. 

I will leave that challenge, as the first one I am really second guessing myself on. 

 

I have had been given the task to pull data from a REST API into a Drupal 8 Paragraph, to be rendered on any specific page. The API would provide the data for a profile, showing in a listing, and a full bio. 

I wanted to keep this as simple as possible, and at the same time, make it cool. 

For this task, I decided to use Vue.js inside a template. I felt that this would give me a way to work with Vue in a way that is not as common - inside a Drupal 8 template. 

I created a Paragraph type called a Profile Listing. In that Paragraph, I added some fields that I would be using to control the API call. In this case, a related taxonomy, limit, and offset, and a few other fields.

The Template

Using a template I created for that Paragraph, I did some markup tricks to get twig to render correctly. Notice the {' '} wrapping the {{ profile.firstname }}.

{# string wrapper is to prevent Twig processing the Vue vars #}
<div id="App">
  <div v-for="profile in profiles" class="card">
    <h2 class="name">{{ '{{ profile.firstName }} {{ profile.lastName }}' }}</h2>
  </div>
</div>

This allows the HTML to not be filtered in the template. This does make it so that ticks ` have to be used instead of single quotes inside that template.

You can also write it this way:

<div id="App">
  <div v-for="profile in profiles" class="card">
    <h2 class="name"><span v-html="profile.firstName"></span> <span v-html="profile.lastName"></span></h2>
  </div>
</div>

Next I pulled the CDN versions of Vue into the template, as well as Axios, a data management plugin.

<script src="https://cdn.jsdelivr.net/npm/[email protected]"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>

Then inside a following script tag, I write the app. Since the app is inside the Paragraph, all field values can be used in the markup, allowing you to filter based on the values. This is a very shortened and modified version, but you get the picture.

<script> const myApp = new Vue({
  el: '#App',
  data () {
    return {
      profiles: [],
      loaded: false
      }
    },
  methods: {
    async getProfiles(id) {
      const = 'https://example.com/api/';
      let endpoint = 'profiles' 

Notice the following API call, which includes the field values to filter the result.

  try {
    const resp = await axios.get(url + endpoint + '?args[0]=
      {% if content.field_setting|field_value %}
        {{ content.field_setting|field_value }}  
      {% else %}all{% endif %}
      &limit={{ content.field_limit|field_value }}  
      &offset={{ content.field_offset|field_value }}');

      this.profiles = resp.data;
      this.loaded = true;
     }
     catch (err) {
        console.log(err)
      }
     },
   },
   mounted() {
    profileParams = 'all';
    this.getProfiles(profileParams);
  }
});
</script>

The result is pretty awesome. Now anytime that paragraph is used, the app loads the Vue app, with the REST data.

 

I enjoy making the web look good.

This is something I struggle with in my work. I feel that there are a lot of web development folks who just don't take the time, or even want to learn about design.

“I don't have an eye for design...”

This is an expression I hear more often as an excuse as to why a "style guide" has not been followed. This makes me question why I can see the obvious patterns in a design, and other developers can not.

Does this come from a lack of interest?

I sometimes feel that is the case, but don't actually believe that is the case for all. Why then is it so hard for some to understand design, and how can we help these folks to learn?

Decoupled Drupal, what does that even mean? When I first heard that expression, it took me a while to understand what it really meant. To be "decoupled" from something, means to remove a connection, or coupling. What we are doing is not really removing that connection, but separating it into different concerns. In the case of Drupal, we decouple the content management from the presentation completely, making Drupal an API. 

If you know what an API is, you are going to understand what Decoupled Drupal is then, it is making Drupal an API only. By decoupling, you are able to use Drupal as a data provider for an application, website, web based application, smart watch, kiosk, TV, all of the above. The potential usage is almost crazy. 

To share some insight, I have been using Drupal 8, as an API for multiple projects since late 2016. In that time, we (Small Robot) have built a conference schedule planner, a voting kiosk, multiple Progressive Web Apps (PWA), including the site you are currently viewing. Each one of these projects has had challenges, in each projects way, as there is not really a "guide" on how to build what you may want. In the past year and a half, at the time of writing, the tools to make Drupal work decoupled have received a lot of improvements, and there is still more work taking place.

Decoupling Drupal is not just about Drupal as an API, it also has a lot to do with the presentation side of things. When you do not use Drupal to output to the theme layer, you now rely on your development to make the site output anything, to any screen. This is a blessing, and a curse. Let's examine some of the pros and cons of this.