Javascript

A lot of people come to JavaScript from languages like Java. And, at first glance, the languages seem kind of similar - they even have similar names! Of course, it soon becomes apparent that there are some pretty important differences. For example, Java is object-oriented, statically typed and lexically scoped. JavaScript isn't these things (except sometimes, when it is). And one of the places that these differences are really obvious is in the use of the keyword this.

Our use case

It has been close to 3 years since Drupal 8 was released. With lots of amazing new features released in every 6 months we are getting more and more excited to see how Drupal has evolved and improved. With the release of Drupal 8.4, it is starting to use ES6 in core. However, there is not yet a standard practice to write ES6 in custom modules and themes.The ideal solution is for compiled JS to still stay in the original module or theme and make our output JS still be compatible with Drupal 8. Drupal is heavily modular, so Javascript files written for a module should ideally be stored with it. This atomic design pattern allows a module to easily be enabled or uninstalled, and makes our code clean. JS files could be also added in a theme level if they are more related to that theme.In this blog we will share our story on how to configure the project with webpack and other tools to facilitate ES6 in the whole Drupal 8 project including both custom modules and at the theme level.
PictureWondering what DDD stands for? Well, DDD stands for Developers Developers Developers! (presumably taken from this famous Steve Ballmers on-stage chant) It is an inclusive, non-profit conference for the software community. This year, DDD Melbourne was held on 15th September 2018 at Town Hall in Melbourne CBD. It was a one-day conference which started at 9:00am and concluded at 5:15pm. Personally, I thought the conference was very well-organized and at $79, it was affordable and being held on a Saturday meant I didn’t have to talk a day off work either. Based on what you fancy, there were several talks to choose from. The agenda, which was finalised after attendees voted on the talks, can be found here.  
It was early morning rush hour on Friday, June 22nd, and the Melbourne winter sun shone on my face. I was attending Angular Conf Australia, being held at South Wharf. Arriving with just enough time to spare, I looked around the conference venue and had a quick chat with some of the participants.After a slight delay, the conference kicked-off with a quick thanks to sponsors and supporters. In this post I'm going to give you a rundown of what I saw next.

ns

Native-what?

If you’re anything like myself before embarking on this project then you might wonder the same thing. Everyone has heard of React Native, it’s a popular technology enabling a cross-platform mobile development experience, but not so many have crossed paths with Nativescript, or {N}.Nativescript is a framework with a similar goal to React Native, providing the ability to publish native apps for both major platforms, iOS and Android, whilst only maintaining a single (mostly) JavaScript codebase.  It is available in three flavours: standard, Angular, and Vue.js, allowing developers with experience in the latter two frameworks to use their existing skills whilst building for mobile.Put simply, it’s a JavaScript runtime inside a native app, translating code on the fly into native elements.  In this post, I’m going to tell you about a few of the nice experiences we’ve had recently developing with Nativescript, as well as a few of the not so nice issues that were encountered, and whether we’d use it again.

Server-side rendering a React app is a miracle on-par with childbirth and modern air travel.

OK, that opening sentence was a little over-the-top. I apologise to birth mothers and those in the aviation industry.

Let me start again: server-side rendering a React app is...kind of cool.

That said, it can be a little tricky to get started, especially if you're trying to do it with an existing app.

In this post I’ll explain one way you can implement server-side rendering (SSR) for an app that's using  React Router v4 and Redux Thunks.

Along the way we'll discuss the fundamental difference between JavaScript clients and servers, how it forces us to change the way we do routing, and the small "missing-link" that enables us to bridge React Router v4 with Redux thunks.

We'll build up a simple example to demonstrate. I'm going to assume you've got some knowledge of:

  • React
  • Redux
  • React Router v4

However, you are not required to have knowledge of:

  • Childbirth
  • Aeronautics

Let's do this.

One of the hottest JavaScript libraries out there right now is React. Whilst there are many good reasons for React being so popular, the main reason my team picked React for our new project is because of the commonality between React and React Native. The concepts and the language are the same, so if you can write React, then you can write React Native. There is also the benefit of being able put both in the same project and then share business logic between them, which is precisely what we need to be able to do.

There are a number of ambitious projects out there that aim to eliminate duplication between platforms by using a common set of React primitives. react-native-web, ReactXP and react-primitives spring to mind. However, these rely on not only a common set of components, but also a common approach to things like styling and animations.

Whilst we wait for the dust to settle on which is the best generic solution to use, my team has come up a simple approach that extends upon a pattern that is already quite well known in the React community. In this post I'll outline this approach.