Posts

Modularity vs. Abstraction. Which is More Important?

Coupling? Bad. Coupling is the enemy of modularity. Coupling creates the need to understand the inner workings (implementation details) of multiple functions/objects/entities in order to understand what the code is doing. Abstractions? Good. Abstractions are a natural concept in this world. I do not need to understand how a car works in order to drive mine. In programming, being able to use functions and components without understanding their inner workings is a sign of well-designed abstraction. A clear and tight interface that is easy to work with is a sign of good code. Good modularity with bad abstractions? Could be better. It's not fun to read, but at least you know where everything is. This tends to create large components and classes, but I see it as the lesser of two possible evils. Bad modularity with good abstractions? The worst spaghetti possibl
Post a Comment
Read more

Arrow functions have no context! Auto-binding does not exist

I see this misconception a lot. Even with seasoned Stack Overflow users! Arrow functions intrinsically have no context. Read more about it here . Very first sentence. An arrow function expression has a shorter syntax than a function expression and does not have its own this, arguments, super, or new.target.
Post a Comment
Read more

Unit testable components pt.4: Testing the Redux data flow

Testing actions within actions Testing redux is verbose. Sometimes it is even difficult. But it doesn't matter where you do it. It will always be challenging. The difference is that the DOM is irrelevant for my approach to testing. I use redux-mock-store to test my actions. No need for enzyme. One less moving part to deal with. That is the whole point of this testing style. Here is what a sample test would look like The action process const processHomeMount = () => async (dispatch, getState) => { try { const type = getState().home.topSearches.focusedDateRange const { endDate, startDate } = createPresentDateRange({ daysAgo: 100 }) await Promise.all([ dispatch(fetchPopularSearches({ type, limit: TOP_SEARCH_ENTRY_COUNT })),
Post a Comment
Read more

Unit testable components pt.3: Testing components

My approach to component testing There are multiple resources that show how to test components. When you read between the lines, they are actually describing their philosophy on how a component should be tested. My tests are basic and practical because my components are dumb My components have the following properties No api calls Small encapsulated components Minimal Redux actions As a consequence, my tests have the following principles Shallow mount component directly. Ignore Redux's connect higher order function (HOF) in test
1 comment
Read more

Unit testable components pt.2: Redux and separation of concerns

Use global state management, like Redux Production size codebases are completely unmaintainable if local component state is exclusively used. Don't even try. React +16.3 introduced their own global state management system, the context api. But even then, I find it to be lacking base functionality. If you want those niceties, I don't think you should reinvent the wheel when redux is so functionality-rich with a huge open source community that backs it. I use the features you get from redux to keep my components virtually free of business logic. Opinion: Thunk is the only Redux middleware needed There is a lot of middleware out there, but I find redux-thunk to be more than adequate for my needs.
Post a Comment
Read more

Unit testable components pt.1: Overview

Bad tests are worse than no tests This code should be changed or refactored, but that would mean I have to update my tests... Testing UI behavior is really hard, and you can get lulled into writing sloppy tests. Sloppy tests are unmaintainable and encourage "behavior locking". It's a problem that only grows as time goes on. Testing React components is hard Frontend testing requires, in one form or another, a mocked DOM, which is a beast in its own rite. Your tests can't be run like a basic function, because the true environment is the browser. Which is what enzyme was created for. It's a mandatory supplement to jest for component testing. C
Post a Comment
Read more

My dogmatic thoughts on TypeScript

Hello, my name is Andrew and I love TypeScript. In my audacious opinion, JavaScript has some glaring issues that simply can't go away. TypeScript, on the other hand, is like a breath of fresh air to almost everything I find lacking in vanilla JavaScript. What is TypeScript? Most importantly, TypeScript has type checking. As a superset of the language, it doesn't change anything under the hood, but it has an incredible amount to offer. Type declarations The 'Type' in TypeScript is exactly this. As a web developer, I come from Ruby and JavaScript land (with a dash of R). I had no idea what beauty there is when you declare a type. A computer is a lot better at keeping track of types than I ever will. Do runtime errors even exist?: Compilation and the smart as hell linter Real time type checking. Real. Time. Type. Checking. Failing compilation is A LOT fa
Post a Comment
Read more