Two Rules Of JavaScript Async/Await

Ever wanted to write a JavaScript function that makes a HTTP request and then returns the results? Sounds simple, but the “and then” part of that sentence includes a lot of complexity. That is because when you make an HTTP request — it is performed asynchronously. This applies to jQuery AJAx, fetch, Axios, Nodes’s HTTPS module, etc.

I’m not going to cover callbacks and promises. I want to ask you to forget about all that and learn two rules. With those rules, and a modern JavaScript runtime, you can write a function that solves the requirement I gave before in a few, highly readable lines, using async/ await.

I say highly-readable because what I love about async/ await is that you can read the code and get a much easier sense of what is going on. Instead of understanding then/when/catch/error/whatever, you see the request on one line and on the next line you see what is done with it.

In this post, I’m going to give you two basic rules of async/ await and some practical examples of their use. It’s a hard to explain this concept, but the code is short and readable, so you should be comfortable, when you’re done to start experimenting with this new API.

Rule One Of Aysnc/ Await

You Must Use The await Keyword Only In Closure That Is Declared With The async keyword.

Inside of this closure, we may use awaitbecause the async keyword is used when declaring the function.

The await keyword is the real magic of async/ await. Before you can use it –see rule two — you must know rule one. Rule one shows us how to create closure that can use the await keyword. How? We type the async keyword before a function. 

Got that? That’s rule one, you’ll see examples when I explain rule two under the next heading.

Rule Two

Inside Of An async Closure, If Another async Function Is called With The await Keyword, The Next Line Will Not Run Until That Line’s Promise Has Resolved.

In this example, line 7 will not run until the Promise created on line 6 has been resolved or rejected.

In this example, I’m using the fetch API, which creates a promise. That’s all been made invisible by using await. Instead of using a then() callback, I’m just awaiting the result of the function.

Notice that the before I declare the function I used the async keyword. That’s another example of how rule one works. This function says async in front of it, so I can use await inside of it.

You can use this asynchronous function only inside of another asynchronous function. For example:

Inside of an async function, we can await the results of an async function.

For a more complete example, here is a more abstract version of getMostRecentPost() that works with any site and then another function that calls it twice and after awaiting those results, returns both posts.

One async function calling another async function using await.
fetch API

That’s The Whole API! Use It!

In this post, you learned two rules of async/ await and that’s all you need to know to use this powerful new feature of JavaScript. It will make your code simpler in a lot of cases.

Want to learn more? I’ll leave you with a Wes Bos video:

Redux(-like) State Management In And Around WordPress

This post is a companion to my talk for the JavaScript for WordPress conference. The talk is supposed to be titled “State Management with Redux in WP” but I always end up changing the title last minute.

In this case, Zac and I honestly didn’t know enough about Gutenberg when we came up with the topic to know exactly what it would be about. We had some theories when we discussed it in this video a few months ago:

Watch The Talk

Josh Pollock – Redux with WordPress – 2018 JavaScript for WordPress Conference
Screen cap from the talk!

Slides

Here are the slides for my talk:

Helpful Links

Example Code

Because this talk will be streaming, some people may have issues viewing the code. Also, I used Carbon.sh to generate screenshots of example code to ensure they looked good. That means you can’t cut and paste from the examples, or read them with a screen reader, which is sub-optimal.

So, here is an image gallery of the code samples with links to the actual code it is based on. Now you can see the practical, real world application of these concepts.

This example code is based on the Caldera Forms Processor UI library, which is what I’m currently working on andand Caldera Forms’ Gutenberg block.

A Dumb App Component

Presentational Component

See full source code

Component PropTypes

A Dumb Component Nested In App

See full source code

Tests For A Dumb Component

See full source code

Higher Order Components

Example From Gutenberg: With API Data

The Provider Higher Order Component

See full source code

Container Component – withSelect

See full source code

Container Component – withDispatch

See full source code (same as above)

Container Component Wrapped With State

See full source code (same as above)

Actions

Action Function

See full source code

Testing Action Functions

See full source code

Selectors

Selector Functions

See full source code

Testing Selector Functions

See full source code

Reducers

Reducer Functions

See full source code

Testing Reducer Functions

See full source code

Resolvers

Resolver Functions

See full source code

Testing Resolver Functions

See full source code

Registering A Store

Pattern

See full source code

Complete Example

See full source coe

Using @wordpress/data Store In A Gutenberg Block

See full source code

Using @wordpress/data Store In A React App

See full source code (same as above)

Some Quick Thoughts On LoopConf

I was super lucky to be able to attend LoopConf last week. Ryan Sullivan and his team put on an amazing conference. I’ve never been to a fancy developer conference before, and I had a blast. Thanks Ryan for having me! I just wanted to share a few observations about what made LoopConf special and share my recommended videos playlist.

Before I go on, I should point out that while I don’t usually stay in hotels when I travel — I prefer AirBnB –Me and Roy Sivan being super classy by hotel fireplace– the Little America hotel in Salt Lake City where they put us up was classy AF. I didn’t know what to do with myself in such a big fancy room, but I super enjoyed sitting by the fire in the lobby and being classy.

One side of the fireplace had statues of dogs. The other side had a painting of wolves howling in the snow. Apex Classy.

Our REST API Workshop And Something New

Caldera Learn BannerRoy Sivan and I gave a 6 hour workshop on using AngularJS and the WordPress REST API. Honestly, we were worried we couldn’t fill 6 hours, but we actually ran out of time at the end. We had almost 40 attendees and people seemed to get a lot out of it.

I have embedded our slides below, and we also put all of the example code to Github. There is a ton of practical examples in there, some not finished to provide a start point for your own work. Some examples are running live on CalderaForms.com right now.

If you’re wishing you could attend an in depth workshop about the REST API from Roy and I too, don’t worry. We recently announced Caldera Learn. This new site will offer live webinars, recorded courses and code communities for anyone looking to level up their WordPress development skillset. It’s going to be awesome.

The Main Event

Photo by:  Anna Anikina

Our workshop was the day before the main event. LoopConf was a single track conference with excellent talks. They also did a great job of accommodating the hallway track. The room that meals were served in was open all day with the live stream playing. This was a great way to network and watch the talks. I wish WordCamps would do this.

The talks were a lot more focused on philosophy of code, then code. Not that there were not code examples. I really liked this trend for non-workshops.

For example, KAdam White talked about why the WordPress REST API was important for JavaScript developers and why he built his node.js client for the REST API, before showing code for a React app using both tools. Similarly, Natalie MacLees and Nathan Tyler shared their experiences learning React. They provided tons of React and general JavaScript resources in context of using the WordPress REST API.

John Jacoby Jones (JJJ) didn’t really show any code at all. Instead, he talked about lessons from Unix Philosophy that could be applied to WordPress. Andrew Norcross talked about improving our community by acknowledging and dealing with unacceptable conduct that happens in our community.

All the nerdy talks on how to code something or why to code something a certain way were book-ended by business-focused keynotes. Josh Koening of Pantheon talked about how the web has trended away from open source recently as companies have packaged what we created for the open web  in better experiences. He made an excellent point that most people can’t afford what free software costs — time and education.

Jason Cohen of WPEngine spoke about building a bootstrapped business. While he talked about pricing and product design, the best part of his talk was about managing yourself. This especially rang true for me when he talked about focusing on 2xing revenue over shiny features.

I’ve been working on both, and beating myself up over not delivering all the shiny new features I want for Caldera Forms. Those would be done if I wasn’t also working on a new tool that we’re testing right now. Then again, February is looking like a 1.5-2x growth for us versus January, so yah.

I really appreciated both of their talks and spending time talking with both Jason and Josh during the event. I was imagining LoopConf would be all out nerdy-codefest with out a ton of networking. But I got both.

Next Generation WordPress

Photo by: Alexey TopolyanskiyIn 2014 I went to WordCamp Milwaukee and saw two talks on the future of WordPress. Ryan McCue and Rachel Backer presented the beta of the WordPress REST API and Andrew Nacin talked about the WordPress REST API and the WordPress fields API being the basis for a modernized WordPress.

I was super-excited for the vision they shared, and got on the REST API bandwagon pretty hard. Of course, things turned out a bit differently then we expected then. At LoopConf Ryan gave a talk called “Next Generation WordPress”.

He talked about going from the blog era of WordPress, to the CMS era of WordPress and now the platform era of WordPress. Echoing what Matt Mullenweg said in the State of the Word about what got us here is not going to get us where we are going, Ryan suggested a new direction.

While State of The Word was all about user experience, Ryan talked about developer experience. I loved this obviously, as there is a reason I prefer to develop most things in Laravel than in WordPress these days — the developer experience — there has to be a balance here.

WordPress is a user-centered platform and that should never change. But, for users to get an improved experience, both from core as well as plugins and bespoke sites, we need to make it easier for developers to fit those needs. Ryan is, per usual a man with a plan. Definitely watch his talk, do what you can to contribute and let’s hope he gets a reasonable fraction of what he’s asking for there.

Vegan Food, Also Videos

I didn’t expect their to be such excellent vegan food in Salt Lake City, but I was impressed. If you’re ever in Salt Lake City, which I recommend strongly, check out The Vertical Dinner.

I’m still working my way through videos of talks I missed, but I created a highlights playlist from both LoopConfs for you. Check it out:

 

Fun Challenges With Recent Caldera Forms Updates

cropped-CalderaWP_Icon_512x5121.pngLast week, we release a new version of Caldera Forms and a new form translations add-on for Caldera Forms. These were both fun projects to work on and I wanted to share a more technical overview of some of what I did on those projects than I gave in the official release post.

I hope this post is interesting and useful to all WordPress developers, whether you are a Caldera Forms user or not. But if you’re not, maybe it’s time to try it 🙂

https://calderawp.com/2016/11/caldera-forms-translations-and-more/

 

Caldera Forms Translations

Photo by: Ben MoorePreviously, When using Caldera Forms or most other form builders on a multi-lingual site, you had to have to create multiple forms, one per language. That is a pain to manage. Making one change meant editing multiple forms.

Caldera Forms Translations is our new translations add-on. One forms, many languages. I originally was planning this as a feature of the core plugin since we didn’t want to make it a paid add-on. That said, figuring out if a form has translations, then if each field has a translation, and then if that translation is in the right language introduces a bit of overhead to form rendering.

It’s not that much, and its worth the trade-off in exchange for the functionality. But this is one of those features that is great for certain users and not worth it for many, so an add-on makes perfect sense.

The interface for this plugin was a lot of fun to build. It’s actually the first time that we’re using the new Caldera Forms REST API. I will be blogging more about the challenges of implementing the WordPress REST API in a legacy project soon.

I actually did the first pass at this plugin using admin-ajax. I thought it was just going to be one ajax action I need for the admin UI. Turned out I needed three.

You can see the commit where I deleted those callbacks here. But I can best summarize how messy things become validating and authenticating these type of HTTP requests get with this:

if( cf_translate_can_translate() ){
        if( ! empty( $_POST[ 'language' ] ) &&  ! empty( $_POST[ 'form_id' ] ) && ! empty( $_POST[ 'fields' ] ) && is_array(  $_POST[ 'fields' ] ) && ! empty( $_POST[ CF_Translate_AdminForm::nonce_field_name() ] ) ){
            if( CF_Translate_AdminForm::verify_nonce( $_POST[ CF_Translate_AdminForm::nonce_field_name() ] ) ){

That’s terrible and doesn’t even get into sanitization. I think it was the third time I had to refactor that when I decided to add the Caldera Forms REST API infrastructure to Caldera Forms 1.4.4. Previously I had infrastructure and some implementation on the 1.5.0 milestone.
The REST API routes for this plugin has three endpoints. One is for saving settings. The other two are for adding and saving languages.

This add-on supports more than a hundred languages. I don’t want each field to by default to support all of those languages. So, in the UI, there is a selector for languages and an add button. This makes an API call to get the field data, and insert it into the local variable that tracks the languages of the form.

The JavaScript for this interface is a bit experimental and doesn’t use our normal UI framework. I’m playing with new ways to build UI. This add-on was an experiment in using a more structured system. I ended up with a pretty modular system that separates each part of the UI into its own closure. That’s good, because I will probably replace each part one at a time as I continue to use this add-on for experimenting with UI systems and figure out which JavaScript framework we will use in the future.

I will admit that some of this modularity was a bit of overkill and I definitely broke some of my self-imposed rules in order to finish it. Still, I think it would take minimal refactoring to pull one part of the system out if I wanted to replace it with something else, or reuse it elsewhere. Also, it works, which is the point.

One thing I am very happy with is how the class that handles translating fields during rendering works. You can read the source here. This class is a good example of using dependency injection — it takes the form configuration through its parent’s constructor — and using inheritance to create a reusable system. Its parent class is a system for conditionally adding a filter. I might add a similar system to Caldera Forms itself, I’m not sure yet.

Caldera Forms 1.4.4

Photo by: petradr

The new version of Caldera Forms is mainly a bug fix release, with a few enhancements. Most of the bug fixes were to resolve accessibility issues, as we continue to work towards our goal of being the most accessible WordPress form builder. Mainly the new improvements are infrastructure for add-ons and custom development. The REST API infrastructure will get its own post soon.

The biggest improvement in this new version is how file and advanced file fields handle uploads. One of the trickiest thing about building a form builder is dealing with the fact that most form submissions use more than one HTTP request. A validation error means another request may be made. Also, our advanced file field uploads multiple files via multiple AJAX requests and then the main submission happens.

As a result, when the main submission is being processed for a form with an advanced file field the $_FILES super global is empty. These fields allow for saving files to the media library and/ or attaching the files to an email.

If both options are selected, that’s easy. We upload the file to the uploads directory, add it to the media library and then attach that file to the email. When the file needs to be attached to the email, but not saved to the media library, that’s where it gets tricky. The file needs to be saved to the server so it can presit between sessions, but users are right to expect the files to not stay there forever. That creates a privacy issue and disk space usage issue.

My solution for this scenario, which is based on a conversation I had with Micah Wood when we had dinner last time I was in Atlanta, was mainly written in my my car as my wife and I drove back from Atlanta. I introduced a new class to Caldera Forms for handling file saving and implemented it in the existing callback for file fields.

This new class manages files on the server and introduces a concept of a private file. Private files are stored in an almost randomly named sub directory of the uploads directory and deleted later. That dub-directory names is named using a hash that can be created predictably, but only by the server, not an outside observer. As a result I can find the directory later and delete it.

Choosing when to delete that file is also a challenge. It should be deleted after form submission, but it needs to be available when the email is sent, though that email may be disabled. In addition, I had to account for files uploaded to form submissions that failed validation, and were never completed.

So, I wrote two ways to delete it. The first was to set a single CRON to delete the file(s). If form submission is successful, the files will be deleted by the time it runs, but its a good fallback. The other method hooks in at the last action that would be run if no email is set. It checks if the email should be sent. If not, it deletes the files. If an email should be sent, it adds a hook to run after the email is sent, to run basically the same callback.

Read The Source Luke

I hope you found this article useful and that you dig into the source code I’ve shown. Reading the source is the best way to learn.

Writing articles like this is something I’d like to do more of because most of my articles on development are a bit divorced from the real world. That’s fine, I’m teaching a principle most of the time and contrived examples are needed.

The real world is a lot messier than a tutorial. Improving a large code base and fixing bugs without breaking more than 30,000 websites running that code is a challenge. It’s a lot of fun, and its a great way to learn.

 

Getting Started With Modern WordPress Development: What You Need

I’m teaching a few workshops this month aimed at those looking to level up their WordPress development chops. It’s got me thinking a lot about what you need to do quality WordPress development.

It’s a very subjective question, what software to use, what principles to value, what resources to learn from… So I wanted to share my thoughts on what is necessary for getting started. The list is less about software, and more about concepts because in the end, it’s about the wizard, not the wand.

Tools

You can write code in notepad and FTP it up to a shared host and hope for the best, but to do it right you need some basics tools. Here is my opinionated list. I’ve broken it down into “basics” and “important”. The first category is things you should have right away. The second list is important, but can probably wait.

Basics

Code Editor and IDE

A code editor is a specialized text editor designed for writing code. I like Atom as my simple code editor. It’s the application I use when I just need to open up a file, read it and maybe make a few changes.

An Integrated Development Environment (IDE) is more than a code editor. A good IDE provides everything you need to develop in a language. I do most of my work in phpStorm. I use it as a code editor, web server, terminal, sFTP client, Git client, and more. I probably don’t use half of its features.

Git and A Git GUI

Github Social CodingYou must use version control. It’s just not optional if you need to do anything large in terms of development or work with others. It will also be a part of your deployment strategy.

I wrote more about why you should use Git on the CalderaWP blog. WP Pusher, which is an excellent tool for deploying Git repos as plugins and themes, offers a Git course on their site that is worth checking out.

While I use the command line and phpStorm for Git most of the time, I am still a big fan of SourceTree and it’s one of a few reasons I miss using a Mac for my primary development machine.

Local Development Environment

Installing A Site With DesktopServerThe reasons to use a local environment are numerous. The short answer is — it’s faster, more secure, and no one can see your fails.

There are a lot of ways to set up a local environment on your computer.  Here are the ways I recommend, in order of ease of use:

  • DesktopServer – A simple application that gives you an interface for creating local WordPress sites. Start here if you are new to local development. It’s easy and might be all you need.
  • Valet – Made by the Laravel project, but works with WordPress. I use this on my Mac (never figured out how to get it to work in Ubuntu.) Requires Composer, homebrew and a bit of setup.
  • Vagrant – Vagrant creates a virtual machine on your computer that you can use for development. I use the popular VVV project for setting up a WordPress development environment on my main computer.

Important

Dependency Management Tools

Mandelbrot FractalI’m going to go less in depth here, as I’ve covered Composer quite a bit here and on Torque. Seriously use Composer, it makes PHP development better and easier.

Other tools I use for dependency management and task running:

  • Composer
  • NPM
  • Grunt
  • Bower

xDebug

When doing JavaScript development, you can use the browser’s developer tools to debug your code. You set a break point to stop execution and see what the variables equal at that point.

xDebug gives you that for PHP. It’s an amazing tool that takes the guess work, and the vard_dump()/die(); out of development. xDebug comes pre-installed in VVV and works great with phpStorm.

Concepts

Basics

Photo by: veeterzyIf you’re brand new to development, you need to get PHP and JavaScript fundamentals down first.

I’ve written a ton on PHP over on Torque. I recommend starting with my PHP fundamentals article and then looking at my article on using WP_Query to learn object-oriented PHP.

For JavaScript, I like CodeAcademy’s JavaScript course. The book “JavaScript The Good Parts” is also worth reading. Like most WordPress developers, I started with JavaScript by using jQuery and starting in jQuery being a smart start is the consensus we came to when we discussed this on an episode of The WPCrowd, which I followed up with an article on the same topic on Torque.

The WordPress Way

It’s hard to define the WordPress Way, without jumping into WordPress code, which you totally should do. The best way to learn after all is to read the source.

In addition, you really should read the WordPress handbooks:

If you take one lesson from the handbooks, it should be that there is a standard for documenting code and that you should follow it. Inline documentation makes it easier to work with your code, it makes it easier to read your code and it’s super useful to developers who are not familiar with your code.

Principles

I am very much a believer that pragmatic adherence to certain principles will make you a better developer. At a minumum, I think you should familiarize yourself with the single responsibility principle and the do not repeat yourself (DRY) principle.

Class Autoloaders

I’m a huge beliver in using a class autoloader. It’s becoming more common in WordPress, but is still behind. I covered using a PSR-4 autoloader and Composer’s autoloader in an article for Torque.

An autoloader is simple to setup and it forces a logical directory structure and class naming system on to your plugin or theme.

The WordPress REST API

As you probably know, I’m a huge advocate of the WordPress REST API. I think it’s super important for advancing the quality of code and end-user experience we can deliver.

I’ve written a ton on the REST API to help you get started. But, in my mind, it’s not just about learning the REST API. It’s about learning how to write plugins, themes and site-specific code that can be used with theme templates, shortcodes and the REST API.

TL;DR

Photo by: Paula BorowskaPaula BorowskaOk, that was a little long, but here is my summary:

Use local development (start with Desktop Server) and Git (Github and SourceTree FTW.) Composer and autoloaders are awesome. Read Carl and Tom and document your code.

I’ve linked to a ton of free content, mainly by me, to help you learn. I have two WordPress development courses. One on the WordPress REST API and one on modern WordPress development. You should check those out if you want to learn more and say thanks for all the articles and WordCamp talks that I’ve done to help educate the community.

Learning AngularJS For WordPress Development

At WordCamp Miami this year, I showed how and why, I use AngularJS for building WordPress plugin admin interfaces. For our A/B Testing plugin Ingot we chose to build our interface in Angular beacuse it was the fastest and best way to build an interface that had to be highly dynamic.

I gave two talks, one on Angular basics, and then the second one dove into my specific use case. With this information & with a knowledge of how to extend the WordPress REST API you should be able to start creating new & exciting WordPress user experiences.

It was awesome to be a part of a day full of developers explaining why they made their choice in framework. I hope this type of sharing will lead people away from “What framework should I use?” to understanding the strengths and weaknesses of each framework and make that decision on a per project basis.

In Ingot, Angular is a thin UI layer on top of what is mainly a PHP codebase. I needed a really solid AJAX interface — sorry jQuery — that would allow the interface to have lots of different UI states easily available. Angular provides that.

I want to add that while the focus of these talks was Angular, building this way, in my opinion, requires an API-first approach to the PHP code. I wrote extensively about this before. The short version is that it requires keeping the code required for reading and writing to the database totally decoupled from the front-end use, and API code.

How The WordPress REST API Changes WordPress Plugin Development

This approach also requires having your own REST API endpoints. That part of the stack I covered in a talk I gave several times last year, in chapter 8 of my book and part 3 of my course.

http://learn.joshpress.net/downloads/customizing-wordpress-rest-api/

Slides

Video

 

Example Code

Learn More

A Letter To JavaScript

Dear JavaScript,

I’m sorry I ever said mean things about you. It’s about me, not you. You are beautiful and don’t let anyone ever tell you otherwise.

The fact of the matter is I tried to treat you like you were PHP but you’re not. I wanted all languages to be like my first, but you are both unique entities and are both special parts of my life.

Your pal,
Josh