DEV Community: Brendan B

Let's talk about all my insecurities

Brendan B — Wed, 04 Dec 2019 21:20:12 +0000

I'd like to tell you I have imposter's syndrome, but that would imply I secretly think I'm smarter than I think I am, which negates the whole imposter's syndrome thing. The funny thing is, I considered myself both brilliant, and the literal-dumbest-person-on-earth for absolutely all of my professional career, going back long before I started in tech.

Tech is a special case, too. Coding is hard sometimes (okay, a lot of times). The systems that code lives on are big and complex and always changing, and we're constantly getting new concepts and acronyms, FOMO springing eternal. I was sure that, by the time I got to the five year mark in the industry (right about now, at the time of writing) I'd be a software savant, seeing code in my mind's eye writing itself on chalkboards and etch-a-sketches. But some days - like today - that old familiar feeling reasserts itself. I feel dumb.

Let me tell you a story. In 2007 when I started college, I sat down with an advisor, and told him I wanted to major in computer science. I'd started making HTML/CSS websites as a kid in the 90's, and loved every minute of it. But up till that point, in that advisor's office, I hadn't really known how to channel any of that love for making cool websites into a career. I'd worked retail and hotel jobs, and had no real direction as far as life was concerned. So I told the advisor that CS was what I wanted to do, but I was worried, because I wasn't a "math guy." "Well," he replied, with a confident look, "you definitely don't want to get into computer science, there's quite a bit of math in that."

It took me another seven years before I even attempted a computer science course. I still think back to that moment sometimes: although he was wrong for smashing my dreams with such glee, he was right on the details. CS classes are heavy on math, and light on making-cool-websites. I found that out in my first algorithms class, where I was informed on day one that all homework would be solving complex math puzzles in C++. I lasted about a week in that class. I still somehow managed to get an internship, but it required a change in schools and a move across the state. Eventually, though, I fell into a real crisis moment: as the internship was drawing to a close, and as I started realizing I wasn't going to make it through another semester, all those lifelong fears about being too dumb to do anything came back in a rush. Here I was, 30 years old, failing at school, about to lose my only income as an intern, and living in a strange new place with absolutely no plan B. Admitting to failure is one thing, but admitting to being a failure is a big punch in the gut.

This story has a happy end (well, a happy bookmark, don't bury me yet) - the internship eventually led to a full time job, and several full time jobs later I sit here with five more years of experience and just enough confidence to write an article once every five years or so. But still, sometimes, I feel like I don't know anything and I've been faking it this whole time. Writing code sometimes makes me feel like a genius, and some other times makes me feel like a kid who stole a business suit, snuck into a big office building and tried to do a business.

Learning Javascript was fun. Adding React onto that was fun, too. And I felt pretty smart about all that. Even more complex subjects like state management and application structure were fun to work on, because there's a hundred ways to slice that cake, and I'm a big fan of cake. But then there's delivery pipelines, CI/CD configuration, PROD deployments, Webpack (a whole universe unto itself), Gulp (is that still a thing?) and Grunt, Git CLI, NPM scripts, route management, unit/integration/e2e testing (please help I'm scared), API's, endpoints, and a partridge in a... okay you get the joke. All of this is hard enough to keep in your head, but wait, there's more! Pre-commit hooks! Babel/ESlint/Prettier/XO config! Axe complaining about landmarks! What's a landmark!?? Performance metrics! Web components!! SHADOW DOM!!! LIONS! TIGERS! BEARS(please stop making dad jokes it's not even funny Brendan) OH MY!!!

Then there's those 10x (please take with an extra dose of irony) engineers who seem to know everything, and will Well Actually anything you think you know (one reason I don't write very much on technical subjects). Stackoverflow is full of people constantly getting shot down for asking the wrong question, the duplicate question, the irrelevant question, the question with not enough detail, etc etc. So if one didn't already feel dumb enough, there's always someone willing to make you feel 10x dumber.

I'm not writing this to be a solution to anything. This isn't a Five Things You Can Do To Combat Imposter's Syndrome kind of article. I just wanted to say that, if you're feeling down, if you sometimes feel like a kid stuffed in a business suit at the Business Store doing a business, you're not alone. This tech stuff is hard sometimes, and absolutely no one can know it all. Sure, you've got your 10x'ers out there, 10x'ing away. And they'll always make us feel bad, because they'll always know 10x more than us and have 10x more opinions. But that's okay. Let them do their thing. Focus on yourself. They're just ten kids in a business suit. Us? We're smarter than we think we are.

Revisiting Redux with Context and Hooks

Brendan B — Mon, 29 Apr 2019 12:40:00 +0000

I develop a small, internal facing UI, and it's been using Redux for awhile now. The store provides functionality for certain global concerns like API fetching and notifications, but it's a bit unwieldy with all of the connecting and mapStateToProps'ing that has to happen just to inject a basic data flow. The best alternative to using Redux as a global state manager is React Context (from a purely React perspective) but until recently had some issues to overcome.

React Context, introduced in early 2018, is a way to share data deep into a component tree, by wrapping that tree in a Provider, giving it an initial store / values, and then accessing / updating those values in the child components by accessing the context 'Consumer.' The original implementation involved calling that Consumer, and rendering its children as a function with props, the props being the original store/value object from the parent node. But keeping track of all that Provider/Consumer/render propping gets clunky, and results in false hierarchies inside consuming components.

Updating data received from context, too, is tricky. Most people solved this by passing callback functions down with the context values, and using those to pass changes back up. But pairing data with callbacks like that is a little ugly, and it means that every time your data tree updates, it re-instantiates those callbacks with it. Redux's reducers provide a much cleaner way to update state, listening for event triggers that get fired by actions in the component, and updating the part of state relevant to that action. Until hooks, however, integrating reducers and context was a bulky marriage of technologies.

When hooks were introduced at the React Conf I attended in 2018, I saw their usefulness, but didn't understand why people were saying it was a Redux killer (it's not, necessarily, but that's a topic for another day). But when I discovered hooks like useContext and useReducer, things started to click into place. With the useContext hook, you can extract the context values without a consumer or having to use render props, and with useReducer you can extract both state and dispatch without much of the overhead needed by Redux.

Armed with these new tools, I decided to create my own global store/state management system, to rid myself of Redux once and for all (until I discover down the road that I actually do need it, but we'll let future problems live in the future for now). After about four or five iterations, I finally came on a pattern that made the most sense to me, and happened to eliminate hundreds of lines of code, as a nice side effect.

Before we get into the details, I want to give credit where credit is due - this article by Eduardo Marcondes Rabelo and this one by Tanner Linsley were foundational to my understanding of how to put these pieces together, and I borrow heavily from their ideas. I've also seen similar implementations here and elsewhere. The takeaway here is that there's more than one way to peel an orange, and you should choose the way that's most… appealing to you.

For an example, we'll make a very simple React application that lets the user view and refresh data from a 'stocks' API, using both state and actions from a global store. The folder structure will look something like this:

Notice the 'store' folder contains a folder for the stocks' API reducer and actions, similar to how a typical Redux project might be structured.

Our entire application will be wrapped in a StoreProvider to give every child element access to the actions and state, so let's create our index.js to start:

Again, this is a similar construct to how a Redux store would be placed at the top of an application:

The types, reducer, and actions also look very similar to Redux:

This sets up the state for stocks - an 'isLoading' boolean is available to display a loading state, data is populated on a successful fetch, and an error message is delivered if the fetch ran into a problem

This particular action is provided a 'dispatch' (similar to how thunk works) to conditionally dispatch different states based on the response from the API.

Next, let's create a helper function called 'combineStores' that will combine all reducers, combine all initial states, and return an object with both:

Note the comments in this code - this is just a simple example of a combineReducers function that I pulled from an online example - you may want to use something different, even the full blown original from Redux
We'll create two other files in our store folder - a rootReducer to give us a structured object with all the reducers and initial states (namespaced according to their respective folder names), and a rootActions to provide a similarly namespaced object for all actions in the store:

The root reducer uses the 'combineStores' function from the previous example to get the combined state object and root reducer

This delivers all the actions for the store with the dispatch attached to each. If the action is a Promise (as in our API example) then it gives dispatch as a parameter, otherwise it wraps the return value (the action for that case would just return an object with a type and optional payload)

To bring it all together, we'll create the StoreProvider to wrap our application in, which will provide access to all components with the global state, actions, and dispatch:

There's a few things going on here - first, if you're not familiar with hooks like useReducer, useMemo, and useContext, the React hooks API docs are a great place to start. There are three important features - the useStore function (which is actually a custom hook) returns the values from the global State context, and the useActions hook returns the namespaced actions object (more on that in a bit). The store provider is actually three nested contexts, State at the top to provide actions and dispatches access to the global state values, Dispatch, then Actions, so actions will have access to the dispatch. I'm keeping them as separate contexts here, because when the state updates (as it will do when an action is fired off) it won't reinitialize the actions and dispatch. Dispatch doesn't necessarily have to be its own context - it could just be a value passed into the actions getter, but I like to keep it available in case there arises a need for a child component to directly dispatch something.

Before we look at the store being used inside of a component, let's first understand what useStore and useActions are actually delivering. When we call useStore and useActions, they give back objects something like this:

The namespacing is important here to differentiate different parts of the store. I'm keeping names on actions and store the same for consistency (actions.stocks, store.stocks, etc)

Let's go ahead and create our App.js which will hold our Stocks component:

Now let's create that Stocks component:

You can see we're pulling in the useStore and useActions hooks from the store, getting the state values under 'stocks' from useStore and the global actions object from useActions. The useEffect hook runs every time the component updates, but because we pass in an empty array as its second parameter it only runs on mount. So when the component loads, a call to the 'fetchStocks' action will be made, and then again any time the user clicks the 'Refresh stocks' button. For a comparison, let's see what that component would look like if we used Redux:

Things would get even more complex if we allowed the user to modify the existing state (another article for another time).

The choice to use a large state management library like Redux vs some kind of custom variant like this is at least partly subjective, and will depend on the different needs and scale of your application. Bear in mind, too, that tools like context and hooks are brand new, and 'best practices' is still in the eye of the beholder. That being said, feedback is strongly encouraged - this implementation is really just a first effort for something that will hopefully be much more robust in the future.