Ionic Framework – Geolocation iOS Store issues

WRITTEN BY GARETH DUNNE @DUNNEDEV

Geolocation

As I have recently published my Ionic app CoffeeTrail into the iOS store. I wanted to share with you some issues I experienced while trying to upload it.

Android Coffee Finder Application CoffeeTrail
CoffeeTrail

In total, the app was rejected twice due to lingering issues with my Ionic Native Geolocation plugin. These two issues were easily fixed although initially it wasn’t very obvious.

The first, was the lack of specificity when asking for the users location . A modal pops up asking for permission but I didn’t explain why I wanted to use their location. This goes against the iOS human interface guidelines which you can look at here.

I had to add two strings to my info.plist file. In order to do this, open up your iOS build generated from your Ionic project in Xcode.

Search for info.plist in your directory search panel:

 

And add these two strings with your custom location permissions message

  • NSLocationWhenInUseUsageDescription
  • NSLocationAlwaysUsageDescription

After I added these custom messages my error modal looked something like this:

This fixed this initial rejection.

The second issue caused me the most trouble. Apple informed me that there was a second modal showing after the user already accepted the first location permissions one.

As you can see from above, the modal was giving a uninformative output path as my app name, which Apple deemed unfit for a user to see, which is fair enough as its a bit of a eyesore for the user.

This was not a custom made modal so it was coming from a native plugin, turns out it was one of two reasons

  • My Ionic Native Geolocation plugin was outdated
  • The Geolocation plugin was not correctly put into my iOS build output.

When you have added a plugin to your projects config.xml file, it won’t necessarily build into your platform of choice when you run the build commands.

These are the steps I had to run to rectify this:

So now our Geolocation plugin is updated with the latest version and with a custom location usage description

Next we need to remove our iOS platform:

Then we need to save all our plugins:

Adding the iOS platform back in now will also add in all our saved plugins from Cordova:

To make sure you now have the correct plugins run the command:

And compare that list to the plugins in the your build output folder:

{project-name}/platforms/ios/{project-name}/Plugins

These were the two obstacles I had to overcome to get Coffeetrail in the iOS store. Feel free to try it out and give feedback. As I’ve mentioned already it was rejected twice. On my third submission there was an extra processing time so thats something to be aware of if you want to be extra careful when submitting after that. Took an extra 4 days to be looked at.

I feel after finally submitting it I’m ready to undertake a React Native application.

Keep posted!

Want a job in web development? Learn a framework.

WRITTEN BY GARETH DUNNE @DUNNEDEV

When browsing information about web development careers you might stumble upon junior or entry level developers asking about the correct way to get hired. Very frequently there will be advice given along the lines of:

  • Learn pure JavaScript.
  • Know the ins and outs of Vanilla JS.
  • Do not learn a framework until you know the intricacies of JavaScript.

And while I think all this advice is coming from a good place, its not practical.

This is somewhat of a controversial opinion when looking at online forums such a reddit webdev or reddit JavaScript. But lets take a step back and look at the facts here.

You are a junior developer with basic knowledge of JavaScript, you look at job postings online, what do you see?

Well, nearly every frontend position is looking for you to work with either Angular, React or Vue and no position is seeking someone proficient in vanilla JavaScript.

So if you were being practical, you should jump into one of these frameworks and learn how to use your basic JavaScript knowledge within the constraints of that technology. Doing this alone could increase your employability significantly.


Not Encouraged

But why is this considered a bad idea by the masses? Well it conflicts with the idea of what a good programmer should be about. The idea of what a web developer should know in order to give themselves the best chance possible to use deep knowledge that allows to debug and problem solve in the most efficient way possible.

But again, as much as I agree with this, its not practical for someone who has just entered the industry, is urgently seeking a junior position and who has possibly switched his/her career halfway through. This also applies someone who has just finished a bootcamp

Experts in the web development community have every right to demand high standards of programming, this is a highly skilled field that people devote massive amounts of time to and something they are truly passionate about it. But people entering the industry don’t have to brush up their JavaScript to the degree expected by most purists.

Why would someone in this position spend all this extra time going in depth in vanilla JavaScript when they can learn how a framework works and be able to code inside the context of this framework and land themselves a job as soon as possible.

You have to remember this isn’t someone who wants to adhere to the best coding practises currently available, at least, not yet in their career.

The most likely situation is that this person will come to terms with some of the key elements of JavaScript while working inside their chosen framework. From this point, he/she can then become proficient in the more in depth parts of the language.

Now let me stress, this is not ideal for the industry nor does it strengthen the quality of developers available to the workforce. But to deny that this isn’t the quickest surefire way to land a frontend entry position is foolish.

Abstraction

We can tie this back down to one of the most essential programming concepts, abstraction.

The latest of these in demand frontend frameworks give us a layer of abstraction to work within. This layer of abstraction is supposed to provide us with a new environment to work in, while hiding the previous complications behind the scenes.

This is exactly why a junior developer can begin learning inside the constraints of this framework, and improve their JavaScript while doing so.

Will they become an expert in JavaScript this way? No of course not, and this is the flipside of working in a abstracted environment. It hides the complexity that you could otherwise learn.

Another aspect that has to be considered  is how the latest frameworks are integrated with the latest in JavaScript practises.

Frameworks like Angular, React and Vue have standardized the use of the latest from ES6. This further adds to the argument, that you can easily jump into these frameworks and learn current and key fundamentals of Javascript.

Features like ES6 arrow functions:

Ternary operators

State Management in React

Anyone who uses these features will inadvertently broaden their knowledge of JavaScript and become more attractive to employers.

Recruiters

We also can’t ignore the dominance of external recruiters in the web development industry. I know from personal experience, as I’m sure many others  do, that these recruiters are hounding individuals with specific criteria ie, which framework do you know?

And while normally I’m the one complaining about the lack technical knowledge that a recruiter has, this is something that someone at entry level can take advantage of and be fast tracked to an interview.

Learn a framework, build a few small projects and you’ve already launched yourself into better position than you rightfully should be. You have to remember that the application of a language will be almost completely be inside the boundaries of the framework. Everyone will tell you that you can’t learn JavaScript this way but disregard these notions as if you are in the start of your career its only logical that you will learn as you go along.

A lot of the community will disregard this idea and I myself can see how it initially devalues the quality of junior developers but I like to be realistic and practical about these things.

Simply put, specialising in what people are looking for fast tracks you to a job and at the end of the day, landing that initial job can be the first step in developing your technical ability.

Technical prowess will come later, launching your career is paramount.

How to use Firebase to host your Web Application using a custom domain

WRITTEN BY GARETH DUNNE @DUNNEDEV

In comparison to a few years ago, there are a wide variety of ways to deploy a web application. Many will vouch for Heroku for prototyping and I tend to agree. Its a great service to deploy an app free of charge with the option to pay for premium features to scale up.

Another great option would be Github Pages which allows you to host a website or web application by deploying one of your repositories. It gives you a url to view your repository such as :
https://username.github.io.

Again, this is another great option for getting you application live.

The best option that I have been using at the moment is Firebase hosting. Its similar to the other options but allows you to stack extra services on top such as cloud functions. Heroku, of course, also lets you run similar server side functions and its backend and is a lot more flexible.

And although I might come back to compare all these providers the main thing to take away from these services for the purposes of this post, is that Firebase automatically provides SSL encryption. This makes it very easy to link it to a custom domain purchase from domain name sites. In my case, it was NameSilo, who I find dirt cheap without the shadiness of other low cost domain providers. Its reliable with a great albeit uninspired interface.

This is all taken from an experience I had when deploying my random beer finder web application.

This is an application that uses some nice animations from a frontend Coursetro tutorial in combination with RxJS Observables and requests to BreweryDB API.

Be sure to check it out here.

So lets deploy our web application and apply our custom purchased domain.

Setup Firebase

Full instructions from the Firebase documentation are listed here, however I’m just going to cover installing it via NPM.
Run the following command in your console window to install firebase tools globally:

Now, in the directory of your desired project, you now want to initiate hosting for Firebase:

From here you can dictate how you want you Firebase application to be configured.

Say yes to public directory and configuring as a single page app:

You should then create your project in the Firebase console here.

You project has now been initialized with Firebase. Once you are ready to deploy move onto this next section.

Deploying

When ready to deploy your Angular application to Firebase we want to build a production version of it.

Run the command:

You application will be built and the output is usually in the dist folder. You can now do a full firebase deploy with the command:

Or if you just want to deploy the hosting services

When finished your console will indicate what url your deployed application is being hosted.

In my case it was something along the lines of :

https://random-beer.firebaseapp.com

Custom Domain

So the final step in this process is to verify your purchased domain to Firebase. Firebase will also take in any other subdomains you might have and redirect it to your deployed Firebase app url.

We will need to navigate to the Firebase hosting console.

You will have to change the DNS records in order to indicate to Google that you own the domain name. We want to create a TXT record in our domain backend. This is made relatively simple in NameSilo and most other domain hosting interfaces will be quite similar.

Log in and navigate to the domain manager:

Select your desired domain and click the DNS Records option.

From here we want to add two TXT record with details from our Firebase console.

After about an hour Google was able to recognize these new records and establish that I was the owner of the domain. Google will then ask you add two A records with custom IP addresses that they will give you. From here we will do the exact same thing on your domain provider except adding two A records instead using the details from our Firebase console.

SEO

As you may be aware, a typically bundled and deployed JavaScript web app using a modern web frontend framework is not crawlable or index able by most search engine bots.  To solve, it can be a complicated beast, especially for Angular applications.

The most common approach in order to make your Angular app SEO friendly is to allow your server to generate your HTML markup dynamically. In some cases, this can be easier said than done and was mostly done with Angular Universal.

However, I found it needlessly cumbersome and I think I have found a great alternative specifically for Firebase hosted applications. The folks at Angular Firebase have come up with a fantastic tutorial for this using Rendertron. An external service that allows your site to serve dynamic SEO friendly markup only to search bots while serving your users the standard JavaScript version.

I really think this is the future of SEO for web application so I highly reccomend you watch this video.

Conclusion

Its proven relatively pain free process to transfer a domain name over to our hosted web application. This seamless process is one of the reasons I’m looking at Firebase Hosting more longer term. Apart from just hosting, there are many other added features such as cloud functions which are particulary useful for deploying server side code alongside your application. I hope to cover that soon.

Comparing Package Managers – Whats the best for you?

WRITTEN BY GARETH DUNNE @DUNNEDEV

A package manager is regarded as a collection of software tools that automates the process of installing, upgrading, configuring and removing computer programs.

The concept of using a package manager is no longer new to the web development community. In fact, we are now 5 years+ into a cycle since package mangers such as NPM have been introduced.

And with that introduction they have brought with them their own quips and hazards but generally speaking they have much improved our development lives.

The ability to keep a package frequently up to date is worlds apart in comparison to how JavaScript developers used to manually re-include an updated script into the header of their websites or application.

As well as this, the barrier to entry of someone in the community wanting to publish their own package or plugin has been significantly reduced leading to more packages being available than one could possibly comprehend learning about.

In this post, I want to compare the main package managers available to you and how they differ from each other and which one is most appropriate for the stack your using.

You might also want to check out this learning resource for all things Node.js.

Yarn

Yarn is Facebook’s own published package manger and with it promises fast, reliable and secure dependency management.

It has quite a good system of caching dependencies. You might think that this seems like something that all package managers should have but its particular powerful here as its allows one to redownload packages offline.

This allows for continuous development while not having an active internet connection.

Yarn can be installed with npm and replaces npm in your terminal.

Or on OS you can install it using brew

Yarn also prides itself on its speed and up until npm5 was released it really had the advantage.

Now, both package managers are alot closer to each other when comes to measuring install times. Have look at this comparison here for more detail.

The speed differences between these two now are less significant and most users really won’t be able to tell the difference. But there are other differences with npm5 which leads us into the next package manger.

NPM

The most notorious package manager, NPM (Node Package Manager) would be considered the most familiar for those within the dev community.

It impresses by being the biggest software registry in the world and also being the most JavaScript focused.

The npm team was also able to address some of its shortcomings with the release of npm5 back in May of this year.

These changes improved its speed significantly while also adding default lockfiles which enable all npm installs to be reproducible.

This means that previous discrepancies between users on different development environments are no longer having differing experiences with the same install

What may have previously thought as a bug was rather just two different versions installed of package. This has been rectified now.

As a JavaScript developer you can’t really go wrong with NPM, its CLI is simple to use and it might just be the most user friendly option out of all the package managers.

Turbo

Perhaps one of the most interesting package managers on this list, Turbo is a new NPM client that functions inside the browser. It claims to be 5X as fast as NPM and Yarn and you can look at its release post here.

Since it runs in the browser its predominantly used for Web IDE’s such as StackBlitz. One of the benefits claims to reduce the size of your node modules by half.

This is definitely one to watch as Web IDEs become faster and more reliable.

Nuget

NuGet deals with all .NET assemblies so it is a very Microsoft focused package manager. It supports .NET native packages written in C++It is seamlessly integrated with Visual Studio and comes pre-installed with it.

It is generally thought that it is inferior to the latest versions of Yarn and NPM in terms of user interface, speed and performance. However, it still contains a large repository of packages with a focus to distribute server side libraries. Any releases from Microsoft are usually distributed on Nuget too.

Bower

Bower was originally created to be a specialized front end development package manager. Since then it has been made somewhat obseltete by changes to npm3 and Yarn.

While some have gone as far to consider it legacy, its quite dated in terms of functionality. It still meets the need of being a package manger but thats about it really.

Some have even called to see it depracted in order to make way for and encourage NPM + Webpack/Browserify workflows. You can have a look at that here

Conlcusion

As with all branded tools for web developers there can by a lot of blind loyalty to one specific technology or in this case, package mangers.

From researching different aspects of whats out there I really don’t think any developer will go wrong choosing between NPM or Yarn. They seem to be the most feature rich of whats available and its very unlikely that you will need one over the other in your workflow.

Hopefully this cleared up some of the confusion around what package mangers suits your needs. I intend to update this blog a lot more regularly for 2018 while also getting the web app version sorted this month.

Stay tuned.

Hybrid Desktop Applications – Another part of the JavaScript ecosystem?

WRITTEN BY GARETH DUNNE @DUNNEDEV

JavaScript hybrid mobile applications having taken the spotlight for the last few years with the idea of writing code once and using it among many platforms.

These hybrid application frameworks such as Ionic, use HTML, CSS and JavaScript to build versatile WebView mobile applications. This exact same stack is also available to be used to build desktop applications.

Specifically, the platform Electron is the leading framework for building hybrid desktop applications in this fashion.

Check out this Git here and a great introduction here.

Interestingly, this is yet another way for JavaScript developers to utilise their own array of tools to avoid native platform specific desktop programming languages such as C# and Java and to instead use Angular to create desktop based application that can be deployed onto OSX, Windows and Linux.

Popularity

First of all, you might be wondering if anyone is actually using technologies like Electron? You might be surprised, when looking at some well established products and applications that are using this hybrid tech stack I came across the following notable players:

Personally, I use at least two of these on a daily basis. Its quite impressive that some of these big names have already adapted Electron so quickly.

Most notably, however, is that Visual Studio Code (my favourite code editor to use) was built in Electron. This a text editor that is on par with its IDE counterparts in terms of functionality.

It is reassuring to know that there are already well-established applications out there but what advantages could Electron have provided them?

Productivity

To be honest, this is always going to be where a hybrid framework shines. In terms of managing resources, a dev team with the same skillset (HTMLJavaScript, Angular, CSS) can be spread out between web applications and desktop applications that can written once and deployed to multiple operating systems.

Cross platform sharing of code is always going to help a developer or teams productivity. Electron lowers barriers to entry for desktop development by providing these familiar tools for web developers. Their familiarity with these tools will in turn increase their work output and productivity.

Say what you like about how it fares against its native competitors, however, you must admit any company will be intrigued by that productivity boost alone.

For some companies this is enough of a compelling case to use it, despite some performance and stability trade offs.

Performance

This is quite possibly the most controversial aspect when Electron is compared to native desktop programming languages.

Some articles such as this would really try and put the nail in the coffin of frameworks like Electron before its given its fair share as an alternate way to create performant desktop applications.

And while the title of the article is offbeat and bit outlandish there is certainly a very good argument to say that hybrid desktop applications will never compare to its native counterparts due to things like having to use a web browser in a desktop app which puts a strain on resources as it is.

However, why exactly do hybrid applications have to match native performance? As memory allocation in our hardware is consistently getting better I see no problem creating apps in Electron. It can be a lot more efficient then natively developing every single possible version of an application that needs to be on OSx, Mac and Linux.

Again, I want to use Visual Studio Code as a focal point here. It of course is built using Electron and makes a strong case for being a tight competitor to major code editors like Atom and Sublime.

In terms of functionality it is as robust as major text editors such as Atom and Sublime, with seamless Git integration and an extension package window to boot.

Getting Started

I’m no expert on Electron and hybrid desktop applications in general. So this post just sums up what I’ve noticed so far. It really seems very promising and yet another way to hone your JavaScript skills and apply them to a new area of app production.

How it compares to natively developed desktop apps should only hold huge weight at a more enterprise level and even with this in mind, it doesn’t seem to stop some very big names for utilising it for major enterprise apps.

The most important thing to take away from this as a frontend dev is to know that you have yet another big section of tech product development that you can move into. Making us in more versatile in what we can achieve.

Ultimately, I suppose you have to ask yourself when will this JavaScript growth start to plateau? How many sections of development can JavaScript be adapted to? So many years ago it was boxed off as just a web-focused technology in conjunction with HTML and CSS, but its meteoric rise in other areas is now undeniable.

It’s unclear whats going to happen next but it is on a upward spiral so the future looks very promising. It may not be for the native purists because a lot of web based programming goes against what makes native languages for desktop great.

For such a promising framework such as Electron I haven’t found too many learning resources for it. Here are some of the best I’ve found so far.

I hope to cover more of this framework in the future.

Ionic vs React Native – What is the best choice for your mobile app?

WRITTEN BY GARETH DUNNE @DUNNEDEV

The mobile app development market isn’t what it used to be for developers. In contrast to 5 or 10 years ago, the Android and iOS stores were locked to you as a developer depending on your ability to learn the native languages related to either option.

We are now given a plethora of choices when it comes to determining the right technology that you want to create your applications with.

Technologies that allow you, as a developer, to be no longer restricted to one store depending on what language that you know.  Mobile development using JavaScript opens up so much more opportunity for a developer or a team seeking to finish their own ideas while also having a much broader market to publish it to.

These choices are usually categorised as either WebView app development (Ionic, Xamirin) which runs an app through a web browser on a mobile phone. Or native app development (React Native, NativeScript) which use core native components through an API to run in a mobile application.

In this post, I want to compare Ionic to React Native, as personally, I would consider both to be key frameworks in each of their respective fields of hybrid app development.

If your looking for a learning resource for React Native you can look here.

I have also published my Ionic app to the Android store (soon to be iOS as well) so fell free check it out if your keen on seeing an Ionic app in action.

Android Coffee Finder Application CoffeeTrail
CoffeeTrail

Language

Both of these technologies are built around using JavaScript. Ionic is based around the Angular 5 framework. This is quite beneficial as you have full access to the Ionic CLI to scaffold a project, generating your components/pages/services via the command line.

Ionic’s combination with Angular means that you will be using TypeScript by default which is an awesome subset of JavaScript and allows you to define types while having object oriented JavaScript code.

TypeScript can also be used in React Native but will take another step to setup initially or you could just check out this template here.

React Native is based on React.js a very popular frontend development library. Its focus is on its reusable components that are shared between mobile and web versions.

Both frameworks use the latest in ES6 practises including classes, arrow functions, templates string etc. Basically, on a core JavaScript level they are both stacking the latest and greatest.

I wouldn’t be too concerned either way here, if you are a fan of Angular and how it scaffolds its projects, services and components then Ionic might be more appealing.

On the flipside if your already familiar with React.js’s style of functional programming than React Native will just be a continuation of that with its own style of native mobile components.

Ease of use

A lot of the ease of use of an Ionic application can to attributed to the readily available list of Native Components and its CLI generator.

Ionic provides these native components plugins such as Geolocation or Google Maps with relative to ease to install.

Simply add them using Cordova (which comes with the Ionic framework)

And then import them into your project using ES6 import syntax.

The documentation for these native plugins is actually quite verbose and its clear how you can utilize various additional methods to get the most out of your desired plugin.

In contrast to this React Native uses APIs that are accessed through the global navigator object. You can then call any relevant methods that are related to the native functionality that you want to use.

For example:

On the navigator.geolocationobject you can call any of the following methods getCurrentPosition(), watchPosition(), and clearWatch().

Check out the full list of React Native API’s here.

Overall, I think I’d edge towards Ionic on this one. Apart from the wide range of documented plugins. The core CLI in combination with Cordova gives you plenty of commands and tools to generate resources, splash images, building tools as well the recently released Ionic Dev which provides you with an app to test your creation on any device you want.

For me, these testing tools allow a dev to access a wide range of devices and increases the accessibility of using Ionic over React Native.

Performance

Perhaps the most defining aspect when comparing both of these technologies, performance is always a big worry when dealing with hybrid mobile applications.

This is where React Native truly stands out. React was fast to begin with and was even comparable to natively developed app speeds for the most part. However with the release of React Fiber  it is now much more responsive to browser events.

Not only this but Fiber assigns different priorities to different types of UI updates with the more important ones taking priority when React re-renders.

For a more detailed guide to React Fiber I’d recommend this post here by Mark Cruz.

To summarize, React Fiber works smarter, not necessarily faster. The priority given to more important tasks results in a faster application.

In comparison to this Ionic is still not bad performance wise. In fact, it has come an awful long way since its first version.

Ionic 3 was released with lazy loading modules taken from Angular. This has certainly increased initial loading times of the application as well as subsequent loading of pages and assets.

Lazy loading enables the app to only load the modules that it needs at any given time.  A great feature undoubtedly but still isn’t up to snuff when compared to React Native’s native component library.

Maintainability

Due to of some platform specific code segments of React Native, the ability to maintain an application is a bit more difficult. Whereas in Ionic, a functionality change for example, will be reflected in both iOS and Android builds, for the most part anyway.

Here is a snippet of how to target Android exclusively in React Native:

Importing and using the Platform module is probably the exception rather than the rule here, the majority of React Native components have both an iOS and Android equivalent so in most cases this shouldn’t be necessary.

Its definitely not difficult to target platforms like this but it seems more frequent in comparison to Ionic where I very rarely found myself using platform specific code with the exception of styling some components.

Size

The bundle size of your application plays a big role in defining how big or small your .apk and .ipa files will beI found Ionic to have smaller bundling size overall.

Without doing statistical comparisons for both on compilation code and bundles (which I’ve struggled to find in 2017) theres not much to say here really, React Native’s component library tends to be heavier and this is the price for a faster and closer to native application.

Which is best for you?

Overall, theres quite a lot to digest here. While both are great platforms to launch your app the overall performance benefits for React Native as well as its recently released fiber potential really edges for me.

This really opens up how powerful React Native can be with significant performance enhancements when compared to Ionic.

But don’t get me wrong Ionic really shines in its own way, its fundamental paradigm of write once, use everywhere allows you to usually have consistent code between your iOS and Android versions.

In this way, React Native is more work for its platform specific code but even with this in mind, for me, the performance of React Native still outweighs this benefit.

I have had much more exposure to Ionic thus far but with my recent projects using  React.js and Redux,  I’m really looking forward to applying this way of functional programming to create apps.

At the end of the day, you can use both platforms to achieve your hybrid application goals.  They certainty differ, with React Native really nailing performance and Ionic providing more accessibility.

They both also have a great communities to boot so until one becomes miles ahead of the other your not doing yourself any disservice to your future applications by picking either one.

So if you feel like getting started on either one, I’ve included some sample tutorials that I’d recommend:

 

Angular 5 Released

WRITTEN BY GARETH DUNNE @DUNNEDEV

As of 1st of November,  the latest version of Angular (Angular 5) has been released.
The release is named Pentagonal Donut and is the latest of Angular releases in its semantic versioning release schedule. The release details many additional features which I want to cover here.

Much to the dismay of some of the web dev community the semantic versioning of Angular is to continue with each release being marketed as a brand new version. I personally don’t have too much of a problem with it changing every 4 or 5 months but I completely see why the new iterations may confuse and annoy devs within the frontend community.

Similar to the way that I’m detailing Angular 5 in this post, this release provides an opportunity for those to remarket their courses and tutorials with the shiny new version of Angular.

I haven’t found any specific Angular 5 learning material but this might suffice until there are any updated learning resources.

While I’m sure plenty will cover the new features in great detail, I wouldn’t worry about feeling compelled to learn this completely new version of Angular because in reality these releases don’t tend to be groundbreaking and usually have minor breaking changes to previous versions.

Lets highlight some of the new features.

AOT

During the build time of your Angular applications you had to previously specify AOT (Ahead Of Time compilation) like so:

This is now occurs by default so you now longer have to specify the ng build.

Performance of AOT has also been increased with faster rendering, less asynchronous requests and an overall reduction of download sizes. This added feature really aims to improve the speed of Angular bundling in development and production and is welcome improvement to AOT.

An interesting watch mode command has also been added.

The idea of this command it to enable your application to only recompile when absolutely necessary. Therefore it will be much easier to use AOT in development mode rather than just production mode because previously, the whole application would recompile when a change was made making it only useful for production.

Forms

Some small changes having been made to the forms API. You can now specify to run validation on submitting a full form rather than it occurring on individual input fields.

We also now have the option to specify when to update a inputs fields value or validation state.

For more Angular 5 form examples check out this post here.

Animations

A small change has been added to animations for your application.

You can now invoke an animation when a desired value is incremented or decremented. 

This is a very handy feature as many use cases of an animation can depend on a value changing but having two new aliases in :increment and :decrement allows us to apply a specific animation to a value going up or down, in this case we want the font size and color to be affected.

Http

There has been some minor changes here, including the deprecation of the HTTP API. @angular/http which has now been replaced by @angular/common/http.

Pipes

Pipes have been overhauled and no longer rely on the Intl API. The most common pipes that you might have used that would rely on this are number, percent, currency etc.

The currency pipe now takes a string as a second parameter.

If you don’t want to use the new pipes you can still get access to the older versions by importing DeprecatedI18NPipesModule .

These are just a small snippet of the changes. For an extensive look at all updated pipes have a look here.

Conclusion

While the ever changing semantic versioning may get on the nerves of some of the dev community, Angular 5 a pretty nice update overall.

These frequent big updates are a smart move on behalf of the Angular team. It increases the marketability of the framework and also constantly keeping it in the limelight each time while not providing anything too earthshattering.

I’ve only covered some of the new features here, feel free to check them out in summary by Traversy Media.

I’m also still a big fan of Gary Simon’s content from Coursetro. So feel free to check that out too.

Feel free to check out the Angular release schedule here as well.

Styled Components – Future Reusability

Styled Components
Styled Components

WRITTEN BY GARETH DUNNE @JSDIARIES

The idea of reusable and modular components is often associated as being best practise with the latest and greatest in the JavaScript world. As such, some of the industry seems to be shifting towards creating components that contain a certain piece of functionality that cab exist in isolation. For example, a button or a menu.

In otherwords, this component can be migrated from project to project with little customisation needed to be fully functional. From this idea I would like to demonstrate the use of styled components.

While my personal preference for styling is still using SASS and partials there is no denying that styled components is the evolution of styling modular UI components.

A library called Styled Components is using the idea of module styled React web components.

If Styled Components perk your interest and your not familiar with the ways of React.js you might find it useful to get started with this learning resource.

Most of the guidelines are already covered in the docs here but to install Styled Components into your project enter the following in your node command line:

CSS in JS

For sure, this topic of conversation in particular has to be one of the most polarising within the dev community. It really comes down to personal preference but in the context of styled components template literal strings from ES6 JavaScript are used to describe the CSS to our component.

This is the basic concept of styled components and how it differs from standard CSS/SCSS styling sheets.

I’m not going to cover this extensively here as this a post specifically about Styled Components but if you wanted to get more in depth on this topic I’d recommend this podcast episode by Wes Bos and Scott Tolenski.

Creating a Styled Component

Using some examples from the docs we can declare the styled properties of a title text h1 element.

And its as simple as that these ES6 back ticks provide the styled data properties to our component. It definitely seems an unusual but creative way to describe style properties. But at its core it really is just like declaring normal CSS, there is no issue converting already defined CSS from one of your components or projects.

I think it is quite important that the string interpolation is still very simliar to normal CSS. It will be key to converting developers over to this way of injecting styles in JS because it already feels familiar and comfortable to use.

But this is just a basic implementation you can go on further to manipulate and interact with your styled components in combination with things like JSX in React.

This is where the ability to customise CSS with JS becomes apparent and I would highly encourage you to explore the docs even further.

Media Queries

Media Queries for specific styling at different dimensions are also not a problem using Styled Components. A great example from the Git demonstrates this:

We have created our utility file that contains our specific dimension size.

We can access this specific handheld dimension size by importing our utilty file that we just created and referencing is in our template literal string using the template variable symbol $.

Interacting with Props

In the context of React and Styled Components, we can manipulate the internal properties of our styled component using props that we send down to it.

This is perhaps the most useful thing about styled components as it can be dynamically styled based on a single prop that you send down to it.

Pretty awesome stuff and it really highlights where CSS in JS might be more useful when you want to manipulate a style based on a property or other data.

Summary

As I hope I just outlined, there are a lot of benefits to creating components in this way. In the future, I wouldn’t be surprised to see mass adoption of this isolated component pattern at enterprise level. It would enable a company to create their own JavaScript UI library that could be used across a wide range of projects.

Each piece of the UI could be customised by passing down new props or injecting new template literal CSS.

But this isn’t limited to large scale projects either. The possibilities are really endless for creating migratable components like this and its really another weapon the arsenal of a frontend JavaScript developer.

React Alicante 2017

WRITTEN BY GARETH DUNNE @JSDIARIES

Last weekend I attended React Alicante. Its the first of its type set in Spain’s southeastern Costa Blanca.

With an attendance of over 250 and a wide range of the latest and greatest from the React world, React Alicante delivered some interesting topics ranging from React Native all the way to GraphQL.

In this post, I want to cover the talks that stood out most to me, bearing in mind that there was a lot more covered throughout the event outside what I mention here.

If any of the following talks perk your interest and your not familiar with the ways of React.js you might find it useful to get started with this learning resource..

React-Storybook

Marie-Laure Thuret had an awesome talk regarding React Storybook. She demonstrated how you can use this development environment to document your UI components while testing and toggling various props and actions to see their effects.

Storybook provides a dashboard where you can manipulate various states and props in your application to see the outcome reflected in your desired documented component.

I found it even more intriguing when I saw how Airbnb had implemented it in order to document their own UI components.

While I really do see the value in documenting your React components for large scale projects I can also see its value being diminished somewhat for smaller scale projects as the time spent building a system of UI documentation with Storybook while also having to write tests specifically for that documentation system might be overkill in some instances.

Overall, using Storybook provides a way to create components with more reusability and testability which is always a useful thing for mid to large range projects.

GraphQL

Possibly one the most interesting talks at the conference was by Nikolas Burk, His talk (Building a realtime chat app with GraphQL) was extremely engaging. I was really intrigued at the prospect of using GraphQL as a new query language for my API calls.

It makes sense to me that I should dictate what kind of query I want to send over to my API endpoint. Using GraphQL it seems like I can just define what format my requests and responses should be using a Type face query language which I would describe as hybrid between json and TypeScript.

There are plenty of examples on the site but I’ll give you a brief overview of one here.

You define you request Type like so:

You then use this Project Type in your GraphQL request;

And the data returned is logical and what you would expect from what you described in your request.

Makes sense right? I encourage you to play around with it here.

While I don’t have all that much experience with GraphQL, from what I’ve seen I can attest to it being a great service that can really streamline how you interact with data. Which will make any frontend developers life that much more straightforward.

The response to his presentation was overwhelmingly positive and his company is actively hiring where you will get the opprtunity to work with GraphQL, be sure to have a look at his slides here.

Code-splitting in React apps

A talk by Glenn Reyes detailing code spitting in react apps was a very topical and interesting take on how our JavaScript bundling systems should be working at the moment using the new import() proposal.

Be sure to check out the slides for his talk here.

His talk made me reflect on how valuable the long term caching capabilities of bundling really is. Perhaps the most valuable thing I took from his talk was the idea of only dynamically loading the components you need for your application.

I previously knew of lazy loading from the point of from Angular but seeing it implemented in this way for a React application was fascinating.

Taking a snippet from his slides like so:

The dynamic capabilities of the import syntax allows us to specify when we want this Async component loaded. And because the import syntax actually returns a promise we can use ES6 async and await syntax to wait until the import promise has been resolved. From this point we can then set the value of our state to the ready loaded component.

This seems like a very smart way to preload a component when your component needs to mount. The state will refresh and component will display in the render, some really awesome stuff here.

Redux Forms

A talk by Erik Rasmussen named, A practical guide to Redux Form was very interesting and made me rethink my current system of form validation using React and Redux.

Erik is the creator of Redux Form and he outlined how this library provides an easier way to manage the various state changes of a dynamic form.

Check out his slides about Redux Form here and the repo for it here.

The library comes with a single Redux reducer that you can use to enable various states of the form field properties. For example, the standardised form attributes used for describing the state of form fields such as pristine or dirty.

This is very handy when you want to apply a very specific style change if the user has not interacted with the form yet (dirty) or if all containing form fields and controls are valid which can sometimes can be tricky to manipulate when not using a library like Redux Form.

Conclusion

Overall, the conference offered a lot in terms of providing the latest and greatest in the React world. While I’m sure there is room to grow it was definitely a successful first edition. I’m sure next year will show signs of expansion, a bigger venue and even more talks.

All talks and slides are available here.

So support the JavaScript community and increase you knowledge at the same time by attending conferences like these. Personally I’ve been looking at React Amsterdam in April. Feel free to suggest others!

Want to brush up on ES6? Check out this awesome resource.

Introduction to Hyperapp.js

WRITTEN BY GARETH DUNNE @JSDIARIES

Oh no, not another frontend library I hear you say? I thought we already established that JavaScript Fatigue is very much alive and kicking ?

All these concerns are very valid, however, Hyperapp.js allows a developer to use all the popular functional programming based concepts from popular frameworks like React.js, using a simliar pattern to Redux while also including SVG support, inline CSS, JSX and fully implemented lifecycle events.

If you wanted to know about more about functional programming in the context of React.js check out this learning resource here.

It ticks all these boxes for what a developer really needs from a frontend library while also being the smallest frontend library available with next to no configuration or setup. An intriguing prospect no?

Minimal Approach

With no dependencies included and totalling the grand size of 1 KB it comes as quite a surprise that Hyperapp.js is able to pack in all the functionality that it does but thats the beauty of it really.

Think about the amount of time you are potentially spending choosing a stack, setting up your environment, choosing what bundler you want to use, as well as planning your styling pre processors. The time taken to do this can really add up and can be especially overkill for small scale applications or personal projects. And this is where Hyperapp.js really starts to shine.

Oh, and did I mention it even comes with its own built in Router system? So web apps can be created out of the box. Very impressive altogether.

State Management

As I mentioned, Hyperapp utilises state management based on the Elm architecture. Also included in this small package is its own virtual dom used to in a simliar way as React and Elm.

Included in the Github page is a simple example demonstrating how state is tracked.

In this particular example from the docs, we hold our state information in an object. Our state contains properties that describe what is likely to change for our component. Our actions object contains two different actions down and up that will manipulate our state to be increased or decremented depending on which button is pressed.

If you are looking for a more ES6 compliant way to write JSX you can also use Hyperx with Hyperapp. Check it out here.

And as with most JavaScript state management libraries we always want to keep our state immutable. In otherwords, when our state changes, we don’t want to edit the old version of the state but rather create a new object for the new one.

Immutability is a very important concept for state management and can prevent bugs and errors in your application.

This is very much the way you want to structure your state when using Hyperapp beyond simple demonstrative applications.

In the next section I will mention some resources that display how immutability can be used with Hyperapp.js.

Resources

While I will do plan on writing a post with some various code snippets demonstrating some of the capabilities of Hyperapp.js, I wanted to share two very good and free learning resources that you can use to get yourself familiar with it.

The first is a informative video series by Joe Santos Garcia from CodingPhase:

This is a great step by step course that includes setting up your environment while also teaching about state, actions and immutability.

Joe also makes this course quite accessible to a wide range of developers with clear and concise breakdowns and explanations.

Check out the full course here.

For a more advanced look at the Hyperapp.js paradigm, I discovered a very useful post by Dr. Gleb Bahmutov.

He goes on to discuss more advanced concepts such as reactivity and debouncing using some very nice examples.

Conclusion

There is a lot to be said about simplicity but there can be even more said about simplicity that doesn’t compromise functionality. For me, this describes what Hyperapp.js does for a developer.

I believe that substantial growth is inevitable for this tiny framework. It can be used for small to mid range projects and beyond.

I am considering rewriting the frontend of JSdiaries with Hyperapp. This is due to the fact that it’s so lightweight and hassle free to setup. The simple approach has enticed me somewhat and I would like to use it in combination with the WordPress API to transform this site into a web app.

Be sure to check it out the repo here.

More on this to come!