DEV Community: Ricardo Andrés Pérez

Starter guide to understand Sections on Shopify Themes.

Ricardo Andrés Pérez — Tue, 25 Jun 2024 08:06:11 +0000

Shopify is awesome, and one of the things that I like the most is that it allows merchants to update the UI of their e-commerce sites in a very seamless way, something similar to using no code, and your job as developer is to make a theme as customizable as possible for your clients, so they never will not come to you again for a background color change hopefully.

Thanks to the Schemas, you can accomplish that, and the possibilities are almost endless on what you can make customisable. Schemas are great and are one of the essential parts of Shopify development. To start understanding how schemas works, you must know they can only be written inside .liquid files, within the sections folder.

And they are written outside the html content, just right at the bottom usually. Using the schema tags. What is inside is pretty much a JSON structure. We will get more deep on this later with an example. Another thing to understand is all you write inside the schema will be reflected on the theme editor, which is the back office for the merchants. It’ll look like the section at the right side of the screen.

{% schema %}
…
{% endschema %}

Each page or template, (for example the home page, or the product page) can be composed by multiple sections (up to 25), whereas a section can be integrated by snippets. Think of snippets as components, which you can use to modularize the code. Snippets are added through the code, using the liquid tag render as follows: {% render 'snippet-file-name' %}

Just don’t try to use sections inside other sections, as they were snippets, it is not possible, this tip might save you headaches in the future. The only place where you can call a section with code is on the theme.liquid file, that is a kind of starting point for the whole project.

Before moving on, how to create our section, in case you are wondering how a page is created. You create them by adding a .json file inside the templates folder. Is not the point of this short tutorial to explain the structure of a template file, but I encourage you to check it after finishing this tutorial, on the Shopify documentation. For now it is enough knowing that a template will represent a single page in the e-commerce website, and this file will usually be written dynamically when someone makes any change on the theme editor. You could technically add sections here as well inside the template file, but it’s way easier and better if you do it through the theme editor. Any section added manually to the template file, won’t be accessible through the theme editor, keep that in mind.

Okay, now in order to keep this article as an actual tutorial, let’s go to create our first section. We are doing a hero banner, and will make sure this boy is fully customisable with the help of schema. This is what we are going to be creating.

This hero banner has 3 main parts, the image for the banner itself (1), the white box with title, subtitle and the CTA button with the respective link (3), and the rounded shape (2) that was made with SVG but since our sizes can change depending on the content on of the box, we allow merchants positionate them by themselves.

This is the basic structure of the schema, where the name, is how we will see it on the builder, the tag property, is the HTML tag, used to wrap our component (in case we omit it, a basic div will be used), optionally we could use a class, for further styling purposes.

{% schema %}
{
  "name": "Cool Radius Hero Banner",
  "tag": "section",
  "class": "hero__section",
}
{% endschema %}

Now the settings property is where our component is made really customizable. Shopify provides a set of predefined inputs that we can use, with their own constraints sometimes. In this example we are using the basic ones, but you can find the whole list here.

We are needing an image picker, the type property is where we say to Shopify which type of input we will be needing at the theme editor. As you can imagine the label is for displaying it at the editor as well, and the id is how we reference it in our code.

<img src="{{ section.settings.image | img_url: 'master' }}" alt="{{ section.settings.title }}">


{% schema %}
{
  "name": "Cool Radius Hero Banner",
  "tag": "section",
  "class": "hero__section",
  "settings": [
    {
      "type": "image_picker",
      "id": "image",
      "label": "Image"
    },
  ],
}

If you are new to the Shopify world you’ll be wondering, where the section object comes from. Shopify provides several global variables that store different information depending on which variable you are doing reference, for this particular one, the section object has the information related to that section itself including settings and the blocks, if another section is created on the same page, it’ll have different information related to that new section. I encourage you to see the documentation for each object in order to see what property provides each global variable. Doing hover on the object usually prompts you links to access the documentation.

To provide the content for the title, subtitle and CTA of the banner content we can provide as many settings as we want, so merchants can adapt the UI for their unique needs. These are just a few.

{%schema%}
"settings": [
    //...
    {
      "type": "text",
      "id": "title",
      "label": "Title"
    },
    {
      "type": "color",
      "id": "title_color",
      "label": "Title Color"
    },
    {
      "type": "range",
      "id": "title_size",
      "label": "Title Size",
      "default": 2,
      "min": 1,
      "max": 5,
      "step": 0.1,
      "unit": "rem"
    },
//...
{%endschema%}

Ranges are tricky sometimes, because they have some constraints, like the amount of steps you can provide to them. The maximum step allowed is 101, this means the amount of values so to speak that you can choose from that given range. In case that’s not clear, imagine you are building a stair to go up 20 meters, but you can only give it 10 steps, this means every step should have up to 10 cm or more if you wish. In case you go less than 10cm you’ll have more than 10 steps and will fail to comply with the rule.

The same we did to grab the image, we get the content box information provided in the theme editor through the settings property within the sections global object, as follows.

<div class="hero__text-box">
    <h2>{{section.settings.title }}</h2>
    <p>{{ section.settings.subtitle  }}</p>
    <a href="{{ section.settings.button_url }}" class="btn">{{ section.settings.button_label }}</a>
</div>

And for the dynamic styles we need to create a style tag inside the same .liquid file besides our html content. And place the values from the builder accordingly.

<style>
  .hero__text-box h2 {
    font-size: {{ section.settings.title_size }}rem;
    margin-bottom: {{ section.settings.title_bottom_margin }}px;
    color: {{ section.settings.title_color }};
  }

  .hero__text-box a {
    background-color: {{ section.settings.button_color }};
    color: {{ section.settings.button_font_color }};
  }

  .svg-top-side {
    bottom: {{ section.settings.svg_top_side }}px;
  }

  .svg-right-side {
    left: {{ section.settings.svg_right_side }}px;
  }
</style>

One thing important to understand when working with liquid is think of it like you were doing some sort of server side rendering. Yes my frontend friend, you are some sort of backend developer now. Any value provided there won’t change once it hits the client, please keep that in mind, although you could use JavaScript to modify it.

We are almost done, but if you go to the theme editor and try to find the section you won’t find it yet. In order to make it visible we must provide the presets property on the schema, is how we make it possible include our sections to each template JSON through the theme editor. So don’t forget it.

The next step is to complete the information and customize the section with the inputs that were created on the settings inside the schema. This is what it should look like more or less.

Sections can get very complex, so the more you learn the basics of liquid the better and more fancy sections you’ll be able to create. I encourage you to do the same I did for this tutorial, grab any cool UI component you like on pages like Pinterest or Behance and try to replicate them, is the only way I know to get better at this. I leave you the complete code at my repository, and feel free to reach out if any doubt regarding the code.

Linkedin, X

Do you know how to save your changes with Git Stash?

Ricardo Andrés Pérez — Wed, 01 Nov 2023 15:53:37 +0000

Git is one of the first things people say you need to learn when you get into coding. Doesn't matter your language preference, or the side you've chosen to code (frontend or backend) Actually Git can help so many people in different professions, even writers or graduate students, just imagine having a single folder with a single file for their thesis project. But no, they always prefer to go this way.

Git could be used by almost anyone who needs to version their work, and whose work involves working on a computer. I'm not going to pretend to create an introductory tutorial on Git here, instead I'm going to assume that you already know the basics of this wonderful tool. Actually, I'm aiming this tutorial/article at anyone who's familiar with Git but hasn't heard of storing their changes, to be more precise.

Have you ever been in the situation where you're working on a new branch, and you've made significant breakthroughs, but those changes are still a mess and have some bugs, when suddenly you get a Slack or Teams notification from your manager saying.

"Hey, I need you to fix this bug I found in production ASAP”.

It's Friday at 13:00, the weekend is so close, so you have no choice but to work on this bugfix. What do you do with the changes you know are in the working directory? You run git status on your terminal and seven files pop up in red. Everything is so disorganized that you haven't refactored and even have some debugger statements on your code. As a responsible developer, you know that you should not commit all that messy code. You can, but you may not.

If only there were a simple way to freeze time and return to your masterpiece after fixing that annoying bug that probably takes two lines of code to fix. If only there were, the world would be a better place. So let me introduce you to the git stash command. What comes next seems a lot like a TV commercial from the 90s. Your life will change and your Git skills will skyrocket, you'll feel like Mr. Robot of Git, I can assure you.

So what or what does this famous git stash command do?

In simple words, it allows you to temporarily save your current changes in a stack, and leave your working directory the same as it was before you made any changes. Which will most likely be the last commit on the branch you're currently on, or wherever your HEAD commit is.

See, in this example we have three unstaged files

If we run git log, we will see that we have a commit to which we are applying the current changes. In our case, HEAD points to the last commit for the main branch.

Once we decide to stash our current changes, everything will be restored as it was on that commit. Now let's do our first stash to save our changes to the stash. But first we need to add the files we want to stash to the staging area, so we run the git add . command.

Once you have your changes in the staging area, we need to save them. To do this, we run git stash push -m "my first stash".

Then when we run git status you won't see your changes anymore, but they are not lost anymore, when you run git stash list you will see them like this.

Now you're free to go and work on some other unrelated thing without worrying about your last changes; you can switch branches, create new ones, or do whatever you want (just don't remove your repository, please). Now let's make this even more fun. Let's create a new set of files that represent different changes, so to speak, and stash them as we did before.

Now let’s see what happens when we run git stash list again.

As I mentioned before, the stash behaves like a stack in some way, the newer changes are placed on top of the old stashed changes. But do not worry, you can access them at will using the stash@{n} reference (n can be any number shown in the list) if you want to access the first stashed changes. Even though you couldn’t add a message, I encourage you to always add it, so you can easily tell them apart.

Now let's say you finish the changes your manager asked you to make that were on a different branch, when you come back to work on it and want to retrieve the changes you stashed, all you have to do is run git stash pop and voilá! You have your latest changes back in your working directory.

As you can see, this brings up the last changes we stashed, in this case it was stash@{0}. If by any chance the changes you want were the first ones we made at the very beginning, you can specify it like this: git stash pop stash@{1}.

Note that the pop option removes the changes from the stack. If you don't want to remove the changes from the stack, and want to keep them just in case, you can use apply. So it'll look something like this: git stash apply or git stash apply stash@{1}.

As you can see, this is a really simple, yet powerful and useful command that you, as a great developer, need to know.