Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

About how hard it is to find a front end developer capable of work with Magento

About how hard it is to find a front end developer capable of work with Magento

Is it hard to find someone willing (and able?) to work with Magento. And I'm not talking about finding an already "senior" Magento front end developer with n years of experience with that eCommerce platform and/or working in that specific field already.

No. What I mean is that it is difficult to find someone who is already a front end developer but never worked with Magento. Will he be able to? Will he understand and like the platform? Is he willing to despite what he says during the interview?

I already wrote an article about how to interview a front end developer, and I'm not sure if I strengthened enough the idea of it being a kind of a bet.

How to interview a front end developer and not die in the process
Being an interviewer it’s not an easy task as the candidate’s chances of getting the job depends not only on the candidate’s technical skills but also on the ability of the interviewer to rule on the truth of those said skills in a 60 minutes talk.

In this scenario we're betting twice as we not only need to discover if the person being interviewed possesses the skills to be a good developer but also if he or she can perform with the specific platform.

That fuzzy line between back end and front end within Magento

I encountered a lot of different "profiles" while interviewing. While the spectrum is really broad let me summarize this into two groups (nevertheless, not sure about the names I'm giving to them, but bear with me):

  • Web designers, or people focused only on the HTML and CSS (maybe jQuery?) part of the coding process. People whose main task is to convert a given PSD file into "a web".
  • Developers using the "hard tools" for coding complex logical solutions with, and not limited to, JavaScript and all its modern flavours.

The first group is excellent in that PSD to xHTML conversion process but they sort of depend on somebody to add the functionality to their creations, and the later group fails when the QA team compares what they delivered with the original design files.

So, someone in between, right? Right. But why?, because of that fuzzy line between back end and front end within Magento. :)

It depends on how the company you work for is structured, and how the roles for back end and front end are implemented there, but under my experience I can tell that none of these groups that represents the two extremes of the wide range of developers I interview can work with Magento, or at least they can't on their own as they will always lack what the other groups knows... and we need both on the front end side of a Magento project for it to go live.

Again, under my experience, while working with people that falls into this two categories I either faced the problem of things looking good but not working as expected, or things that do what they're are supposed to do but with so many differences when I open the designs (and if you are thinking "it's only colors", think responsive web design).

How we find that "in between"?

Spoiler alert: I don't know for sure, but I can tell you what I'm doing right now and hopefully it will help you achieve the same as I'm looking for if you're conduction interviews.

I recently had a meeting with somebody from the recruiting team at the company I work for in order to polish the "mechanism" to identify people too attached to the mentioned groups in order to dismiss them at the beginning of the process, and there are a lot of hints in the candidate's CV that you can use.

Exhibit A is this imaginary resume that includes skills such as HTML, CSS, SASS and jQuery, which is excellent because we need those skills. Following we find a lot of background experience building corporate websites only, but never using a CMS as there is no mention for WordPress, Joomla, Drupal, or similar.

Finally, the work experience is a mix of marketing and design, mostly a transition from the later to a developer. The court rules guilty for being too much of a member of the web designers group.

A second example is this also imaginary resume that includes all the fancy words I already used to, such as Angular, AngularJS, React, VUE, Node... you name it... and a background experience that mostly includes working on the back end side of some sites.

I don't have to tell you to which group this imaginary candidate belongs to.

So, again, someone in between. Find that resume that have a mix of the trending topic's keywords for the first and second group, and you got yourself a feasible Magento front end developer. Or work the other way around: burn the resumes that falls into the extremes and what lays in the middle is the people you should interview next.

No group is better than the other

Don't get me wrong... or let me clarify.

I do not think one group is better than the other one, and if you belong to the first one there's no obligation to learn what the other group knows, neither the other way around.

Let me put another short perspective into this: if the company you work for (or the company you applied for, or your company if you happens to have one) really separates this two groups into really two separates job positions, and if you only have to worry about the PSD to xHTML thing because somebody else is handling the functionality... good for you, and go for it, as again this depends on the scenario you're standing.

That's why I mentioned something about the way a company is structured before, because in some places you might not need to worry about the "in between" as it doesn't apply.

Happy hunting.

Check if a user has made a purchase on a VTEX store

Check if a user has made a purchase on a VTEX store

There's no a simple built in functionality on VTEX that allows to check if the current user browsing the store has already made a purchase there, but there's a twisted workaround to get this information.

Before actually going through the guide, this is the idea: we need to create a new attribute in the CL Data Entity that retains this information and this attribute is going to be updated on the Order Placed page doing an HTTP request to the VTEX Master Data using JavaScript.

Sounds simple? Well...

Creating the new attribute

Thanks to the VTEX Master Data API we can get a lot of information about the clients, but if he or she has made a purchase is not there anywhere, that's why we need to create a new attribute that will hold this information.

The new attribute, let's name it buyer, needs to be Boolean, and we need to grant it permissions to be read it and edit it using the API.

Attribute configuration on the Client Data Entity

All existing registered users on our store will have it in null or false until we changed it to true after a user performs a full checkout process.

Updating the attribute

After the user performs a purchase he will end on the Order Placed page that says something like "Em breve você receberá um e-mail no endereço john doe@example.com com todos os detalhes do pedido". We need to get that email from the source code of the page and using jQuery AJAX performs a PATCH in order to set the buyer attribute in true.

The problem is that we can't directly insert any piece of JavaScript code in the VTEX Smart Checkout. If you're thinking on adding the JavaScript code into any of the orderplaced-* templates, it won't work, the code won't be displayed because of security reasons.

VTEX Portal section

Here's the fun part: we need to use Google Tag Manager to insert JavaScript on that page.

GTM as our Trojan Horse

Since the VTEX Smart Checkout, as any other checkout process from any other platform, is a sensible part of the site and that's the reason why we don't have, directly on VTEX, a way to insert JavaScript code.

If we have Google Tag Manager integrated into our VTEX store it's our lucky day because that tool can add JavaScript on the page, and the idea is to give to GTM our jQuery AJAX request code.

To accomplish this we need to create a new Custom HTML Tag where instead of HTML we are going to add our script. This script.

$(window).load(function() {
    if ($('.orderplaced-sending-email strong').text().trim()) {
        var urlProtocol = window.location.protocol;
        var apiUrl = urlProtocol + '//api.vtexcrm.com.br/storename/dataentities/CL/documents';

        $.ajax({
            "headers": {
                "Accept": "application/vnd.vtex.masterdata.v10+json",
                "Content-Type": "application/json"
            },
            "url": apiUrl,
            "async" : false,
            "crossDomain": true,
            "type": "PATCH",
            "data": JSON.stringify({
                "email" : $('.orderplaced-sending-email strong').text().trim(),
                "buyer" : true
            })
        });
    }
});

Next, on the Fire on step, click on More in order to create a new trigger. The new trigger needs to be a personalized event that will be fired on "orderPlaced".

GTM new Tag

Save the tag and publish the changes on Google Tag Manager. This is not affected by VTEX cache so we should see the changes immediately.

At this point every time a user hits that page, meaning every time an user finish a purchase, the buyer attribute will be set to true. So now in any other page of the store you can use the VTEX Master Data API to check if buyer is true. If so, then the user browsing the site already made a purchase and you can do whatever you want with that information.

Waaaait

This is a delicate move. You are inserting JavaScript into the checkout process so test it very well, you don't want to screw this part of the VTEX implementation.

Code to GET, POST, PATCH and PUT data in VTEX Master Data

Code to GET, POST, PATCH and PUT data in VTEX Master Data

We can manipulate the documents existing in the VTEX Master Data using HTTP request, and it's like the most important thing we should know to dominate this platform's tool.

The official Master Data API documentation breaks down the different HTTP request we can use and explains each part of the request but this information wasn't enough for me to create a working code.

Using and old technique known as "try and failure" I came up with four working jQuery AJAX requests ready to be used to GET, POST, PATCH and PUT data in a specific Data Entity.

Differences between POST, PATCH and PUT in VTEX Master Data
There are small differences between POST, PATCH and PUT that justify the existence of all of them, and knowing this could improve our VTEX implementation.

My goal was to simplify the interaction with the VTEX Master Data during the implementation of a VTEX store. The code is far from perfect but it's a working start.

GET

function getFromMasterData(name, where, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtex.com/' + store + '/dataentities/' + name + '/search?_where=' + where + '&_fields='+ fields;
    var response;

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10.profileSchema+json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "GET"
    }).success(function(data) {
        response = data[0];
    }).fail(function(data) {
        response = data;
    });

    return response;
}

The first parameter here, name, refers to the Data Entity's acronym (for example, CL for the Client's Data Entity) and it's the same for the next HTTP requests.

The second parameter, where allows us to define the filter to use while requesting the documents from the Master Data. For example, email=johndoe@example.com.

Finally, fields is there to specify what attributes we want to retrieve from the results.

Here's an example to retrieve the first name and last name from a client knowing its email address.

getFromMasterData('CL', 'email=johndoe@example.com', 'firstName,lastName')

POST

function postInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.ds.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "POST",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

In this case, email needs to be an actual email address that the code is going to use as an unique identifier of the document that is going to be created on the Master Data, and fields is a JSON object with the attributes and values to send in the request.

Life is better with examples.

var someAttributes = {
     firstName : 'John',
     lastName : 'Doe'
};

postInMasterData('CL', 'johndoe@example.com', someAttributes);

PATCH

function patchInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "PATCH",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

The parameters here works just as the POST's example, where email is the way to identify the document is going to be edited and fields the JSON object with the attributes and values, as show in the following example.

var someAttributes = {
     firstName : 'John'
};

patchInMasterData('CL', 'johndoe@example.com', someAttributes);

PUT

function putInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "PUT",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

More of the same, just like the last two codes. And a similar example.

var someAttributes = {
     lastName : 'Doe'
};

putInMasterData('CL', 'johndoe@example.com', someAttributes);

This is on GitHub

I decided to put this snippets on a Git repository you can find in https://github.com/nahuelsanchez/vtexmasterdataapiconnection.

Feel free to send any improvement you think this code desperately needs (thanks in advance).