react

Modern web applications on OpenShift: Part 2 — Using chained builds

Modern web applications on OpenShift: Part 2 — Using chained builds

In the previous post, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last post was focused on getting your app deployed quickly, this post will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.

Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”

Share
Modern Web Applications on OpenShift: Part 1 – Web apps in two commands

Modern Web Applications on OpenShift: Part 1 – Web apps in two commands

In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.

This first post will cover how to deploy modern web apps using the fewest steps.

The next post will show how to combine this new S2I image with a current HTTP server image, like NGINX, using an OpenShift chained build for a more production-ready deployment.

The last post will show how to run your app’s development server on OpenShift while syncing with your local file system.

Continue reading “Modern Web Applications on OpenShift: Part 1 – Web apps in two commands”

Share

Best practices with React and Redux web application development

Introduction

In the past year, our team has re-written one of our internal apps from Angular to React. While earlier React experience on the team ranged from new to experienced, we learned a lot along this journey. Much of what we learned has been from experiencing pain points in development, or inefficiencies, and either researching others’ best practices or experimenting with what works best for us.

Continue reading “Best practices with React and Redux web application development”

Share
Angular, React, and Javascript framework fatigue

Angular, React, and Javascript framework fatigue

Introduction

I’m an avid follower of Hacker News and many various programming related subreddits. There is a constant flow of posts where the author expresses fatigue, weariness, and many times backlash at JavaScript and the plethora of front-end frameworks. Much of this conversation surrounds React and Angular and then other frameworks such as Mithirl, Meteor, Ember, Vue and others (and there are many others). The conversation many times will go X is the best framework, or X is not the best framework Y is, and the reasons, or much consternation that X or Y is short lived and will be superseded soon by Z. Then many times it is just complaining about X, Y, Z, and frameworks and JavaScript in general.

I’d like to offer a few thoughts counter to this outcry of fatigue in the industry.

Overview

What if you viewed the churn and the constant creation of frameworks and libraries as a positive growth factor. What if you viewed the JavaScript ecosystem as parallel to the machine learning ecosystem.

Continue reading “Angular, React, and Javascript framework fatigue”

Share

React.js with Isotope and Flux

TL&DR To integrate React.js and Isotope you need to tell Isotope of changes to the DOM through Isotope’s API (remove and addItems).

Overview

Pairing React.js with Isotope is not particularly difficult when dealing with static content. However, pairing the two with dynamic content does get a bit tricky. The problem with the combination is that Isotope, by default, expects a known set of DOM elements so that it can make computations internally. When the elements change, which will commonly happen in a dynamic environment, especially when doing ajax calls in React, the solution is not as simple as you would expect. Isotope needs to know of each change to the DOM, specifically each removal and addition of the items being tracked. React.js provides a suite of lifecycle hooks so we can tell Isotope when something has changed, but Isotope, by itself, will not just work if all you do is seed it with an initial set of DOM elements from a React render.

Isotope will sort and filter to your heart’s content with initially loaded data, but if you want to load more data or reload data in the DOM, then Isotope is completely unaware of that new data (referring to React DOM updates and new DOM insertions/deletions). Also, frequently, the first set of props sent to child components is null or empty. The good news here is that you can still use the best of React with the best of Isotope.

Continue reading “React.js with Isotope and Flux”

Share

Have some CoffeeScript with your React

In my continual search for the ever more efficient and pragmatic Javascript UI framework I’ve stumbled upon React, but not just React, the special combination of React, Coffeescript, and RequireJS.

JSX is the more elegant way to compose the DOM within React classes, however, it does require an additional compile step, and there is a bit of added complexity when integrating with RequireJS.

It would be hard to give up JSX and go back to building the DOM with plain javascript, the syntax isn’t so elegant, and it gets quite busy. Coffeescript, at first thought, may seem like a lesser alternative; I will propose, however, that it may just be equal to more practical than even JSX.

Continue reading “Have some CoffeeScript with your React”

Share