DEV Community: Mario Loncarek

Awesome Shopify Resources for 2022

Mario Loncarek — Mon, 14 Feb 2022 09:04:18 +0000

Shopify released a lot of new features in 2021, and naturally new tools and resources needed to be developed to cover new features. Next is a list of awesome Shopify Resources for 2022 which will help you to create modern Shopify storefronts.

1. Dawn

Dawn is Shopify's own open source theme with performance, flexibility, and Online Store 2.0 features built-in and acts as a reference for building Shopify themes. Its great for using it as a starter theme for your new Shopify project.

2. Dawn Figma files

If you will use Dawn as a starter theme for a Shopify project, Shopify give us this great Figma file with all Dawn's components/sections/templates that you can send to designer to speed up the design process.

3. Shopify Markets

In my opinion Shopify Markets will be the biggest update to Shopify since releasing Online Store 2.0 but will be even bigger than that. Markets will finally allow us to create Market-specific buying experiences. That means native multiple currencies, languages, language specific domains, duties collection for each market etc. It's currently available as a preview feature so I suggest that you don't sleep on this one!

4. Hydrogen

Another great open source Shopify resource, but this time for creating headless experience. Hydrogen is React-based framework for building custom storefronts on Shopify which gives you everything you need to start fast, build fast, and deliver the best personalised shopping experiences.

5. Helium

Helium is a great resource for using newest Online Store 2.0 features with modern build tools. Helium will allow you to use ES6, SCSS and hot module reloading for both. Great to use in combination with Shopify's Dawn.

6. HULL

Hull is another resource for creating headless experiences, but Hull is a complete starter powered by Next.js + Sanity.io. It has a lot of features so you can use it as a complete solution for your headless project.

7. Shopify Theme Lab

Another complete headless solution, but this time for the Vue.js fans, and also you can swap Vue.js for pretty much anything if that stack is not suitable for project.

8. goCart.js

A complete open source Shopify Ajax cart solution written in vanilla JS. This plugin includes Ajax cart drawer, Ajax mini cart, add to cart modal, and error modal. Developed by Bornfight's frontend team and new, re-written version will be released this year.

5 tips I wish I knew as a junior developer

Mario Loncarek — Mon, 31 Jan 2022 11:34:08 +0000

Here are some tips for junior developers or everyone who just started taking interest in becoming professional in the area, but especially for those who want to progress as quickly as possible. These tips come from my own personal experience and from mistakes I made which resulted in stagnation of my progress.

1. Kill the ego

This is the most important one. Stop thinking that you already know everything. Stop trying to get attention to show how much you know. Stop saying “I know that”. Relax - everybody knows that you are a junior, they know how much you know and they shape your tasks to fit that fact.

Coming into an agency environment for the first time in your life and thinking that you know something is a good sign of the level you are on. Know that every junior is a company’s investment for the future. It’s not expected that you make money for the company right away because you could not be independent in your work - when you’re a junior, there will always be someone checking after you, mentoring you and helping you when you get stuck. It's OK not to know everything and accept that, you are here to learn and that is what being a junior is.

Killing your ego is the first step in making progress. Thinking that you know everything is the biggest blocker you can do for yourself, and you will not progress or grow until you completely eliminate your ego. Stay humble, hustle hard.

2. Request a good mentorship

Now that you are ready to really learn and understand where you are, and on your path to becoming a better developer and worker, it’s time to understand how important it is to have a good mentor. I was very lucky to have the best possible person to mentor me, which made my skills skyrocket in a year or two. If you don't have one, request this from your company first thing in the morning. If a company would not provide you with a mentor, leave the company, that's not a good place for a junior developer, and it also shows red flags about how other aspects of the company are handled.

Good mentor is a life hack in becoming a really good developer and useful for your company in much less time than it would take you alone (we are talking years here). A mentor will give you all of the answers you need many times faster than Google or Stack Overflow will. Take every advice you can from a mentor, squeeze as much information as you can and absorb like a sponge. Realize what mindset you need in order to be on your mentor’s level. It’s really important to learn how to listen - you are here to ask questions and not to be smart. Insist on constant code reviews, and insist on them to be very critical, and understand that critical code reviews are for your own good. Never take them personally.

Never forget to respect your mentor because he is putting a lot of time and effort into making you a good developer and that is a very hard job to do, because knowing how to be a good mentor is a science on its own.

3. Show initiative

If you want to stand out as a motivated worker, show initiative. That’s what separates people who are only doing their jobs from someone who wants to grow constantly. And that’s what being a good worker really is - a person who is highly motivated and shows initiative. That kind of person adds value to the company and pushes things to be done.

Give constructive suggestions. Take the hardest task that no one else wants. Take ownership of the things you are doing and take responsibility for how they are done. But try to be useful while doing it, don’t just do things for the sake of doing them to show off - meaning don’t be fake!

4. Be the hardest working individual

Work hard and stay hungry. Seek to be the best developer in your company, but compete only with yourself. Not everyone has the same timeline, so never compare yourself to others. You are on your own path and things will come - and that will only depend on you.

Difference between being good and being great is proportional with the hard work you are willing to invest in your skill. Most of the time this will mean going an extra mile in your free time. Having a good life/work balance is important, but I do not regret working hard after my 9-5 job when I needed to understand things deeper because it helped me to get where I wanted to be and to learn much faster.

5. Understand how business really works

Don't think about the money at all as a junior developer. Only focus on learning, progressing and gathering real experience. You want to be on a level on which you are useful for the company and you can create real revenue with the work you do. Until that point you really don't have many arguments for some crazy salary. Money will come naturally, and a good company will never exploit your level, so don’t worry about being hungry, or recognize another red flag of a bad company.

But don’t fool yourself - realize early that when talking about the business side of everything, in the end it’s all about the money. Your salary depends on how much money you can earn for the company through your work. Companies can not do business if they are losing money. That's why employing a junior is an investment for the future of the company because companies lose money until you can be independent in your work and become useful. That also means that your salary will be bigger with more useful work you can do if you're into the money thing.

Of course, you can make more money on your own, but you will never become a great specialist if you don’t start working in the company first - that is where you will be given real experience, big projects and the best possible education. That’s all the things you will not get as a junior developer going on your own. And in my opinion, that will slow your progress - and we’re talking about years here.

Summary

These are the tips that would have helped me a lot throughout my junior years. What do you think about them?
Do you have any other tips or disagreements with any of them? Let me know in the comments.

How to protect GitHub projects from non-reviewed code and force code review culture

Mario Loncarek — Tue, 31 Aug 2021 07:39:24 +0000

In this blog post I will show you a way of protecting GitHub repositories from random pushes of non-reviewed code or pushes to the master/main branch. I’m a strong believer in deploying features via pull requests with code review. I will not get into the question if the branch and pull request workflow is good or bad, I have my opinion which is that pull requests and code reviews are a must for a team that wants to learn, so if you don't agree this article is not for you because it forces all team members to use it.

Code review is a practice that depends on the culture. A culture with no ego, with a great wish for continuous learning, sharing and teamwork. Besides learning code, code reviews will improve your communication soft skills as you will need to be clear and professional without being harsh which will also show you if you are a good mentor or not.

This article will focus on 3 steps to achieve pull request with code review practice:

Workflow in theory
Setting up your project
Creating pull request template

Workflow in theory

1.On GitHub create a new branch from master and use standard naming convention for branches:

feature/name-of-the-feature
fix/name-of-the-fix

Try to do this for every feature/fix to avoid creating very large pull requests which will be very time consuming for reviewers.

2.After you finish working, commit and push your code to your feature/fix branch and create pull request to merge this branch to master branch.

3.Assign someone for code review. The goal here is to learn from each other and to make sure all standards are met and code style is respected, and of course to make sure code does not have any bugs.

4.If there are any questions/suggestions/fixes/changes requested from the person which is conducting code review, that person will request changes on GitHub with clear comments and the process starts again. All comments need to be resolved before the reviewer can accept the pull request, either changes or only answering the questions.

5.After successful code review, the branch will be merged into the master branch and the feature/fix branch will be automatically deleted.

Setting up your project

1. Create `CODEOWNERS` file

Code owners file defines individuals or teams that are responsible for code in a repository. Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. To use a CODEOWNERS file, create a new file called CODEOWNERS in the root, docs/, or .github/ directory of the repository, in the branch where you'd like to add the code owners. I’m a simple guy so I always put everything in the root. You can assign different code owners for different branches. In practice, no one could approve pull requests without code owners approval. This will protect developers from trying to merge pull requests that no one approved.

Example CODEOWNERS file:

* @marioloncarek

2. Manage user roles

On GitHub repository go to the Settings tab and then choose Manage access from the left menu. Here you can define which users can access your repository and what are their roles. Always have at least one administrator, and all other developers can have write permissions. In practice, administrators could override everything from this article and use their privileges to make changes on master branch or force merge without review. This could be helpful for hotfixes.

3. Configure branch protection settings

On GitHub repository go to the Settings tab and then choose Branches from the left menu. Under Branch protection rules click Add rule.

This will open branch protection configuration. Under Branch name pattern write your main branch name (probably master) or any other branch you wish to protect. Configure all options according to this image:

This configuration will:

require pull request reviews before merging
require review from code owners
restrict who can dismiss pull request reviews
require status checks to pass before merging
require branches to be up to date before merging
require conversation resolution before merging
restrict who can push to matching branches
disallow force pushes for all users with push access
disallow users with push access to delete matching branches

Creating `pull_request_template.md` file

When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body.

To make your pull request template visible in the repository's root directory, name the pull request template pull_request_template.md and put it in the root of the repository.

Now when a contributor creates a new pull request they will see the template which will make pull request more standardised and contributors can be reminded about stuff that is important for the project (like standards, code style, build flows etc etc) with checklists.

Example pull_request_template.md file:

## Description

Please include a summary of the change or which issue is fixed.

## Type of change

- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

## Area of change

- [ ] Frontend
- [ ] Backend

## General checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I ran `npm run format`/`yarn format` before commit
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation where needed
- [ ] My changes generate no new warnings
- [ ] I have checked my code and corrected any misspellings
- [ ] I have updated `master` and merged to my branch before submitting pull request
- [ ] My pull request generate no conflicts with `master` branch
- [ ] I requested code review from other team members

## Frontend checklist:

- [ ] I followed guidelines for `HTML`/`LIQUID`, `SCSS`, `JAVASCRIPT` from readme
- [ ] My `Javascript` generate no new console errors  
- [ ] I tested my code cross browsers
- [ ] My slice is pixel perfect for both desktop and mobile according to design
- [ ] I conducted basic QA to assure all features are working
- [ ] I tested responsive for mobile and tablet resolutions

## Backend checklist:

- [ ] I tested admin by manually adding content from zero
- [ ] I followed guidelines for naming admin fields
- [ ] I created easy to use admin experience which is self-explanatory
- [ ] I added description to admin fields in hard-to-understand areas
- [ ] I followed guidelines for naming `php`/`liquid` variables
- [ ] I conducted basic QA to assure all features are working

Conclusion

These 3 setup steps will create strong protection of repositories against pushes of non-reviewed code or direct pushes to the master/main branch. It will force the team to apply the rules and maintain the code review culture.

It’s not always easy to enforce people to follow the rules, but with suggestions given throughout the post, you can automate them quickly, to make sure that everyone follows them.

What do you think about rules mentioned above? Do you have other advices to improve your team’s workflow?

Fast Shopify development with hybrid Debut theme

Mario Loncarek — Mon, 12 Apr 2021 11:48:02 +0000

In this article I will explain how we @bornfight approach developing Shopify themes for clients with a budget or timeline that is not suitable for full custom development, which we prefer. If that is the case we love to suggest starting with a theme to lower the cost and shorten the development time. Hybrid in this context means crossing a theme with fully developed features with tools for modern frontend development like ES6, SCSS and utilizing features like Hot Module Replacement etc.

To achieve this we will be using:

Shopify Debut theme - as scaffolding tool for faster development
Themekit - development tools to interact with the Shopify platform to watch for local changes and upload them automatically to Shopify
Shopify Packer - bridge that allows us to develop using modern tools like Webpack 5 for minification, bundle splitting, bundle analysis, prefetch and easier manipulation with themekit
Bornfight b-creative - Bornfight frontend project template for code style and rules

Why Debut theme?

I like starting with the Debut theme because it's designed and written by the Shopify team and it's free. It offers a great number of features like predictive search, adding to cart with Ajax, product image zoom and gallery etc, basically everything you need to develop a shop with all the features . It's also written quite well and offers some of the latest tricks for making ultra fast websites which is very important for any website, and it's fully accessible. It also comes with a large number of locales for the whole theme. Since we are not using Debut because of the design, its minimal looks is a feature, not a bug.

Introducing Shopify Packer

Shopify Packer written by Eric Hayes is probably the best thing happened to Shopify theme development since Shopify stopped supporting Slate. It's everything we all hoped for and that's a promise. Packer uses Webpack 5 with zero config to compile, bundle, split and minify your modern development technologies and start a server for development with hot module reloading actually working perfectly. It can also create, list and manipulate (delete, download, deploy etc) themes from your shop which is a lifesaver sometimes. I also love using Eric's Shopify Packer because it uses SCSS, Stylelint, ESLint, Babel and PostCSS. It can analyze bundles and have multiple entry points for templates and layouts. It's actually a CLI tool that’s installed globally and you can start a new project or integrate Packer with an existing theme in ridiculously little time. Most importantly you can easily customize all settings for the site and webpack if needed. Eric also provides quick support for the packer so i would highly recommend it and also buy him a beer because he deserves one for this!

Standardising code with Bornfight’s b-creative

B-creative is a modern frontend starter from Bornfight that has standardised opinionated code style and architecture for SCSS, Javascript and HTML/PHP/Liquid. It’s used and contributed by multiple teams. B-creative integrates perfectly with Packer because it uses the same linters so we can just copy their configs and have the same style across all platforms. Templates for SCSS and Javascript modules give us faster development times without having to write the same stuff over and over again. Using b-creative’s SCSS is also future proof because it provides tools to scale the site from 1440px (or any configured base resolution) to any bigger resolution and the site will look the same, while still giving the ability to have the other logic for mobile resolutions.

How to connect all the tools to create hybrid setup?

Thinking about design

Firstly create a new development store which will then come with a Debut theme pre-installed or just install the Debut as a new theme. Now you can provide the designer with the preview link so he/she can look at all the stuff that it needs to style. Goal here is to create a design that follows Debut themes features, components and repeatable sections.

Integrating Packer

Next thing to do is to connect Shopify Packer with the Debut theme for local development and to utilize modern development tools. You can connect Packer with an existing theme or you can create a new blank theme and copy and replace Packers starter theme files from src folder with all of the Debut files you get when you download, which is my preferred way. This will then leave you with all of the Debut assets, config, layout, locales, sections, snippets and templates, along with Packers styles and scripts folder which will then be used to create new custom styles and scripts. Follow Packers docs to generate API access that Packer needs to work with the themekit (same process as only using themekit - private app API password).

Next thing to do is to include Packers CSS and JS files into theme.liquid and then you will load all of the assets from Debut and all of the assets from Packer. You can do the same for password.liquid and gift_card.liquid if needed. You will probably want to delete the Debuts CSS file completely and only use its Javascript features, because it's not likely you will need any Debuts styles. Note that in order for all of the Debuts Javascript features to work you should not remove classes from the liquid files, because CSS classes used by Debuts Javascript are not prefixed with js-* so you can just build upon the necessary sections and snippets with your new custom classes.

To test if you did everything correctly at this point, running Packers start script should open a new local server for assets and you should see unstyled Debut theme files if you deleted the CSS file or styled Debut theme if you did not. If you try to change the background color of the body in SCSS, Packer should compile it and trigger Hot Module Replacement and you should see the background color changing without you reloading. If that works, then Packer is correctly integrated with Debut. To test if all of the Javascript features from Debut are working, try clicking on the search icon in the navigation bar and predictive search should work properly. Try adding some dummy products to help you with testing that feature. Also on the product single page you should be able to zoom the product image on hover and add to cart without reloading with Ajax. If that works, that means all Javascript features you wanted from Debut are working.

Feel free to delete all sections and snippets you don't need and which do not contain any wanted Javascript features but always test if everything is working properly. You can also remove unnecessary styles and variables from Debuts theme.liquid file where you included Packers CSS and JS because you probably will not need them. Also reduce the number of assets from Debut by removing the ones you don't need.

Integrating b-creative

Next we will copy SCSS and JS architecture from Bornfight's b-creative along with linter configs to achieve standardised code. Best thing to do is not to change names of the Packer main entrance point files and just include b-creative’s files inside existing Packer files (they are empty anyways). Don't forget to copy the fonts folder because it's needed for including fonts with b-creative. Your new SCSS and JS will also need some dependencies installed which you can find in b-creative’s package.json file under dependencies. B-creative comes with Bornfight’s modern CSS reset to help you with developing new features.

Test again if everything compiles properly. Now you should expect opening a new local server for assets with Packer, Roboto font used as main font (for testing purposes) and all of the Javascript features from Debut working as tested few steps back. If so, now you have a Debut theme ready for modern local development with modernisation and code style from Bornfight’s b-creative. If the designer followed the Debut’s flow, you will probably only need to write new styles according to design, without even touching JS because you already use all from Debut. This will then drastically change the time needed for development of the shop.

Your final structure should look something like this:

And if everything is configured correctly, running packer start should give you this result:

Final thoughts

I would like to finish this article with some pros and cons of using this hybrid setup for developing new themes.

Pros:

Faster and cheaper development time when designing and developing upon the Debut theme for “projects on budget”
Local development with all of the features
Using modern tools like ES6 and SCSS to develop themes
Hot Module Replacement so you don't have to reload all the time while development

Cons:

Slightly complex for setting up a new project because it needs multiple tools merged into one
Leaves a lot of code bloat from Debut theme, mostly in Javascript that you will not use
Is probably not suitable for anything else then to develop themes cheaper and with tight timeline

If you need Shopify development, feel free to contact us at hello@bornfight.com .

How to improve loading custom fonts with font-face

Mario Loncarek — Mon, 06 Apr 2020 13:48:14 +0000

Why

I would like to start this article with why are we even optimising the font delivery. Have you ever thought about why we are forcing font-face properties to be on the top of our CSS, as a first thing? So we have the font as fast as possible and reduce blocking time for users. By going even further and possibly eliminating time users only see the white (blank) screen on above the fold area, we can directly affect user centric performance metrics which then affect speed index time. So Google will give you a bigger performance score, which is now one of the most important scores for Google page rank.

Background

Optimising font delivery is a process in which developers optimise the way custom web fonts are downloaded on critical rendering path with different strategies. There are few ways to include custom web fonts on a website, and in this article we will be focusing on using font-face to include them. By default using custom fonts means that the files will be render blocking resources. That also means that until the custom fonts are downloaded, the browser has some default behaviours how to handle that. By default, text is invisible and the user is seeing white (blank) screen until the fonts are downloaded. That period is called FOIT or Flash of Invisible Text. Let’s use Chrome Dev Tools’ Network recording feature to further analyse the font loading.

You can see on the image that the browser is not showing text until the custom font is loaded. But that period has a timeout, it will not last forever because it has a bad influence on the speed index. Chrome, Opera and Firefox will hide your text for up to 3 seconds before showing a fallback font. This period is called FOUT or Flash of Unstyled Text.

Good news is that we can control the way browsers handle fonts and optimise the delivery. So we can force or not force some of the periods explained in this text, depending on what we are trying to achieve and what are our performance optimisation strategies.

While there are many ways to do it, this article will explain the most simple way - font-display CSS property.

About `font-display`

font-display CSS descriptor for font-face is a new way developers can optimise font delivery by deciding how custom web fonts will be downloaded and displayed. Works similar to some Javascript strategies to load fonts but this is CSS only solution and that's why it's great. It has auto, swap, block, fallback and optional as potential values. Let’s see what each of these values represent.

Auto

This is the default browser behaviour and typically that would be FOIT and then FOUT if needed (as explained in the “Background” part of this article).

Swap

Fallback text is immediately rendered, so no FOIT time, but we are forcing FOUT. As soon as a custom font is downloaded and available, browser will swap the font. This is the fastest method but also the most aggressive. Swap gives the font face a zero second block period.

Block

No fallback fonts are shown, so we are forcing FOIT and not FOUT. Text will be invisible until custom fonts are loaded, and as soon as the custom fonts are downloaded and available browser will swap the font.

Fallback

Hybrid between block and swap. Browser will give a very short period of FOIT, but if too much time passes, fallback font will be shown and we will have FOUT. As soon as the custom fonts are downloaded and available browser will swap the font.

Optional

Optional acts like fallback but gives the browser freedom to choose whether or not a font should even be used, depending on the user’s connection speed, where slower connections are less likely to receive the custom font.

Which one to use?

My advice would be to not use the properties without thinking or defining what is your loading strategy, what is the priority for rendering and what is more important when the page is loading. So firstly analyze your current situation, define what is important for your loading strategy and then use the appropriate one. After that test visually how user would see loading of the page on various network connection speeds, and see if it suits your needs.