It’s a bit easier to learn Elm if you compare it to things you know. If you know React and Redux, then comparing them can help a lot to understand Elm concepts. I’ve built the same application in React Redux Thunk and Elm so we can compare them together. The end result is a table of things you can paginate through. Comparing these 2 applications is apples to apples. They’re identical to the end user. Yet the technologies behind them are apples to oranges. Seeing those deviations using familiar tech in the same application can help your understanding.
Continue reading “React Redux Thunk vs Elm”
You’ve learned that using
Continue reading “Maybe a Default Good Idea”
Maybe‘s allows you to get rid of null pointer exceptions (i.e. “undefined is not a function”). However, now your application fails and gives no indication as to why. At least errors would leave a stack trace that may provide a hint as to where the problem originated. How does this happen and what should you be doing instead?
Modelling state for asynchronous actions in React using Redux via thunks or sagas is verbose. It requires a lot of code. It also is easy to accidentally miss flipping one of the values and result in a wrong state that your UI then shows the wrong thing. Thankfully there are ways to use Algebraic Data Types to model this state that results in less code in your reducers, whether in Redux or Hooks’ useReducer, as well as in your components. Below we’ll show the 3 problems modelling using Objects can cause and how to solve them using ADT’s.
All code shown below is on Github. The
masterbranch has the
Object way of modelling, and the
types branch has the ADT solutions.
Most of the post below is based on prior art from Making Impossible States Impossible by Richard Feldman, and Solving the Boolean Identity Crisis by Jeremy Fairbank. Like Redux, stolen from Elm.
Continue reading “Easier Asynchronous State Modelling in React Redux or Hooks”
I participated briefly in the Advent of Code 2018. Every year, they post 31 coding puzzles, 2 per day. You have to solve them before you can proceed to next one. I wanted to post about what I learned. I’ve never participated before, and wanted to use it an excuse to force myself to use a Functional Programming language. I use Functional Programming concepts in my day job, but never had the opportunity to immerse myself, and force myself, to accomplish harder challenges in a pure FP language. It was doubly hard because the exercises are NOT what I do at my day job at all and are challenging. They were very hard in a fun way, though. Below I’ll cover the 6 exercises I did (I threw in the towel on Day 7), and explain some of the interesting nuances I found either with the exercise and thinking in FP… and thinking in Elm.
Continue reading “Advent of Code 2018 in Elm Review”