Digests » 135
Maximize technology investments and position your IT org for the future. Learn how today!
this week's favorite
So you decided to start work on your ambitious React app using create-react-app. You begin filling your code with console.log() messages, and soon you realize there’s no easy way of getting rid of them in the production build. I can already hear some of you screaming, “It’s 2018, use breakpoints in <insert favourite browser here> developer tools, dumbass!”. Although you could use powerful debugging tools such as those built into Chrome and Firefox itself, they’re not always ideal, and you’ll often find yourself running back to the good old console to pin-point the issue.
React has definitely brought a challenge that has become a revolution about how we write UI code. But the patterns and practices that are followed by developers is not always in line with the core principles that were the reasons for React to be developed in its first place. When one understands those core principles, one can write React code with more confidence and state-of-the-art way, and thus more efficiently.
I love Redux. It was my gateway to functional programming, and the first such code I ever put into production. Gone were the days of using the DOM for storing your application state and precariously manipulating it with jQuery.
Redux API Utility Library (RAUL) is a library of higher order reducers, an API middleware, TypeScript data types, and other utility functions to make building a Redux Application involving asynchronous calls to RESTful APIs more simple.
Everything is good with your app, until your user makes a POST request while having lost internet connection. Yes, you can just say “whatever… let them do it again when they get back connection”, but that is just not a good user experience. Say the app has some sort of posting feature, and your user writes something lengthy. If you didn’t handle that, the user will have to type up the whole thing again and re-submit when connection is regained.