I’m working on a little basket widget, and while thinking about the model I caught myself unsure about how to handle validation errors. For example: while instantiating a new Product, I need its ID, name and price, but what should I do when price is not a number?

I usually keep my project notes in Workflowy¹ and today I found a new handy thing I can do within it: ramble.

Every now and then, I set out to write an article about some Grand Idea® that just came to me. It usually happens when I read something dramatic rant on something.

The other day I was putting together a little UI to collect emails: an input and a button. So I wanted the email to be take in when the user clicks the button:

The other day I wanted to get some data from an API. The API is giving the information paginated, so I have to fetch it page by page.

For the past few weeks I got a bit stuck with one of my side project’s UI. I have had some vision of how that particular form should look like — which sections there were and how they were positioned, looked quite nice and it worked well so far — but now I’ve got to a point where I needed something else to fit in, and it won’t let me. And there I was stuck.

I have heard that people resist testing UIs because “they change often”, and my oppinion is that from the perspective of “tests as safety net” UI testing is as valuable as any other kind of testing.

OOP wants together behavior and data that change together. FP wants behavior and data separate so that the behavior can be used with more than one kind of data. JS makes the two collaborate well “for a greater good.”

A few months ago I’ve switched one of my side projects from CommonJS modules to plain JS namespaces, and in this post I’ll explain why.

For my PersonSection widget I needed to have a PERSON_TYPES constant.