Continue reading Making environment variables accessible in front-end containers
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”
In the previous article, 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 article was focused on getting your app deployed quickly, this article 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”
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.
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
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”
I’d like to offer a few thoughts counter to this outcry of fatigue in the industry.
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).
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”
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.
Continue reading “Have some CoffeeScript with your React”