Update: Don’t do this unless you really need to run code transforms on your server side code. Use Node module reloading, to swap without the overhead from webpack.
Finally got around to setting up a working express hot module reloading config.
When, a year ago, I started replacing a custom Module
implementation in our
express servers with plain node modules in the name of simplicity, my colleagues
started complaining about no longer having server side reloading.
But with this, developing on the server is back to its former glory!
The purpose is to have only part of an express server work in this way, so that a module being required can update itself in place.
We’ll focus on getting a single module, and all it’s subdependencies to reload during development. Specifically, how to dynamically discover express.Router modules and mount them with reloading on an existing “normal” express server.
If you’re looking for a way to run your entire server through webpack, take a look at Hot reload all the things!
Posted in Programming Webpack - 0 Comments
A mental model for promise chains and error handling, adapted to javascript promises. This post is entirely based on the post and talk Railway Oriented Programming by Scott Wlaschin.
I am quite fascinated with our tendency to focus on the happy code path, which often leaves error handling as an afterthought. It always bothered me, and with the recent popularization of functional programming techniques I think I have finally found a mental model for error handling that I like. It’s the either monad!
As it turns out, promises in Javascript are quite analogous to the Either monad. If you have no idea what that means, I hope the Railway analogy will help you as it did me.
Most functions that are doing external calls like HTTP requests, file system operations or runtime validation will have at least two different outputs: a success case and an error case.
Posted in Programming FP, Promises - 0 Comments
It’s incredible how quickly everything moves in our field. Nothing makes this more clear than looking through our own old code, or in this example old posts right here on the blog.
The quest for not repeating anything makes us do crazy hacks and abstractions, just to avoid having
those very error prone background-color: red;
“duplicated” between two files.
Most abstractions seem beneign at conception, but tend to mutate with time. The more abstractions
it has, the more cracks will appear when you need to move or change an interface between classes/modules.
When a feature needs adding, and falls into the void, who knows where it ends up? Sometimes math.random()
might
as well decide, since “anywhere” will seem perfect when deadlines loom.
Posted in Programming - 0 Comments
Why another post about this?
Most implementations seem to overlook the fact that the changes applied to
delegate.defer
only affect the first promise in the chain, since
by design the defer
function used internally in Angular cannot be modified.
Since we can affect the first returned promise we have our way in. Now to make sure we stay “in”.
Posted in Programming Angular, Promises - 0 Comments
I have long been annoyed with doing form validations in Angular, it just never
felt right. I’d manually link every input to a form with some convoluted
ng-class
conditions, not to mention track form state in controllers and
polluting the scopes with loading indicators.
I just recently found
an excellent writeup
on using the new ngMessages
module in Angular >=v1.3.0.beta.8
have your
error messages prioritized and easily customized. This made me rethink and
rewrite the way I use forms.
Which brought me back to rcSubmit
and the source.
With rcSubmit
the state tracking and loading indicators are handled for us,
but spamming my forms with
<div ng-class="{has-error: rc.form.needsAttention(form.field)}">
...
</div>
feels too repetitive.
If we make a few assumptions on form structure this can easily be avoided with a few directives.
Posted in Programming Angular, Validation - 0 Comments