DEV Community: Kyle Williams

How To Efficiently Update React State For Multiple DOM Inputs Using the useReducer() Hook

Kyle Williams — Sun, 21 Nov 2021 12:48:41 +0000

This article assumes some basic familiarity with the useReducer() hook. Examples are using react-bootstrap but you don't need to be using it in your own project for this to work.

Efficient VS Inefficient

Any DOM structure of HTML inputs would do, but let's say for example you have an HTML form such as the one above. You want React to update state for every change of the input by the user.

Inefficient

Assuming this state object...

  const initState = {
    firstName: "",
    lastName: "",
    street: "",
    aptSuite: "",
    city: "",
    stateName: "",
    zipcode: "",
    date: "",
    title: "",
    status: "fillingOutForm",
  };

Assuming a form input element structured like this...

<Form.Label htmlFor="user-first-name">First name</Form.Label>
  <Form.Control
    type="text"
    name="FIRSTNAME" // Used for the action type
    id="user-first-name"
    value={formState.firstName} // formState from useReducer
    required
    onChange={(e) => {
      const name = e.target.name;
      const value = e.target.value;
      dispatch({type: "CHANGE_" + name, payload: value });
    }}
/>

You could have a separate action type within the reducer function for each DOM input such as...

switch (type) {
  case CHANGE_FIRSTNAME:
    // Return modified state.
  case CHANGE_LASTNAME:
    // Return modified state.
  case CHANGE_STREET:
    // Return modified state.
  default:
    return state;
}

This is inefficient however.

Efficient

The solution to this inefficiency is to abstract outwards in the reducer function.

Given this onChange handler...

// For example, the DOM input attribute name is 'firstName'
onChange={(e) => {
  const field = e.target.name;
  const value = e.target.value;

  dispatch({
    type: "CHANGE_INPUT",
    payload: {
      value,
      field,
    },
  });
}}

...the reducer function could contain this...

  function formReducer(state, action) {
    const { type, payload } = action;

    switch (type) {
      case "CHANGE_INPUT":
        return { ...state, [payload.field]: payload.value };
      default:
        return state;
    }
  }

Normally one would have more cases in the reducer function but this example is simplified for educational purposes

In the code above, a computed property name is used to take the attribute name of the element ('firstName') and update state in the right place. In this case...

const initState = {
  firstName: "Whatever was type in by user",
  // Rest of state properties...
}

Gotchas

Remember how to access the data needed using computed property names. You need to wrap the dot notation object accessor for the action payload object in brackets.
return { ...state, [payload.field]: payload.value };

Further Cleaning

Optimization of code length can be achieved by moving code from the onChange() handler to its own function. It might even be more descriptive to change the name to something like updateStateWithInputValue.

const changeDOMInput = (e) => {
  const field = e.target.name;
  const value = e.target.value;
  dispatch({
    type: "CHANGE_INPUT",
    payload: {
      value,
      field,
    },
  });
};

onChange={(e) => {
  changeDOMInput(e);
}}

I hope this helps!

Connect With Me!

www.kylewcode.com
Twitter
LinkedIn
GitHub

The Watch and Code Intro Part Is Unlike Any Other Programming Course I've Taken

Kyle Williams — Sun, 07 Mar 2021 17:21:04 +0000

While most courses I've taken focus on the specifics of using a particular tool in programming, the introductory portion of Watch and Code made by Gordon Zhu is a course that covers the high level programming concepts such as how to approach coding problems, checking expectations versus reality, and utilizing available resources to solve problems before going to someone else to ask.

Here are the core elements that I felt were most beneficial for me.

The Meta-Skill of Problem Solving

In it's most simplistic state this means to clearly define a problem, list possible solutions, and compare the tradeoffs of each solution.

Using the Debugger

I think there are likely other courses on using the debugger. This one happened to be my first introduction for really focusing on this tool. Remembering to use the debugger has proven to be useful in reducing the amount of time between encountering and overcoming a problem.

Autonomy

I often find myself spending a long amount of time trying to figure out something on my own. I believe I should have a balance between this and seeking help. Gordon emphasizes spending time with available documentation resources before reaching out to ask someone what the answer is. Although this is much slower at first, I believe it would better develop the meta-skill of problem solving than someone who too often encounters a problem and asks for help soon.

Given that documentation is not always helpful, I still will look at documentation first whether MDN or the specific documentation for a tool such as React or testing-library.

This is a particularly insightful tweet Gordon made about being more independent in seeking a solution.

Expectations vs Reality

This was a fresh concept for me. Basically he walked me through the process of writing comments in code that outlined what I expected the code to do. Then after running the debugger or code, I would note the reality of what actually occurred.

The idea is that as a beginner, my expectations will less often match up with reality than someone who is more experienced.

What I also thought was unique was that he would assign percentages to the probability of his expectations being true or false. For example,

Expectation

The variable x will equal number 140. 90% True

Reality

The variable x equals a string '140'.

In this case I was very sure about my expectations being correct and they weren't! So what does this say about how I came to my expectation? This then opens a path to deep learning. I mean to learn how to evolve my thinking to close the gap between my expectations of code behavior and reality.

Slow is Fast

I don't always want to slow down and follow these other concepts. There's a feeling of anxiety that I've got to get somewhere now. This mentality is a problem. Because as trite as it sounds, "Haste makes waste." It's seems a spiritual concept in the sense that one can go slow in order to go fast.

We don't live in a society that supports slow, deliberate thinking and action. In a way, Watch and Code is encouraging a more thoughtful approach to programming that is more involved in the process rather than results.

Setting Up Custom Environment Variables Using dotenv and Node-config

Kyle Williams — Fri, 22 Jan 2021 19:32:54 +0000

The Problem

Mistakes are a great way to learn. Working on Brad Traversy's MERN Front to Back course, I wanted to 'green up' my git contributions graph so I decided I would commit after completing each lesson.

Since it was a tutorial I wasn't worried about any consequences. Shortly after I got an email from a service called GitGuardian about the vulnerability of exposing my database password inside my MongoDB URI because I committed it to GitHub. Now the login credentials are exposed to the world.

I wasn't worried about it because it's a junk database, and believed I would learn how to protect keys and passwords along the journey. It's still important to practice as if it's the real thing.

So as part of good practice, I threw the situation out on Slack for comment by the local Orlando DEVS community.

Some documentation searching later, I was led to the solution.

The Solution

The solution was to store the user database password in an environment variable. For the MERN course, config was already being used provide access to the URI, but it uses a config/default.json file. Being a JSON file meant that I couldn't access process.env because it's a data interchange format and not a file for storing code instructions.

Now onto how it's done.

Set up dotenv

If you don't have dotenv installed, you can get it here.

If you want to only require dotenv on local setups then you need to encapsulate the require function inside a conditional that checks if your app is not in production mode.

For me this was done within server.js.

Add the environment variable

When I had used environment variables before I was interpolating them inside a url on the front-end. This time I pasted the entire thing, a database URI in this case, inside the .env file.

Note

As I'm writing this I have yet to complete the course. I was curious about how Brad approaches keeping these environment variables from making it into the build (I know this happens in React).

After skipping ahead in the course, it turns out he creates a separate config/production.json for production including a separate database (though I think he skips that for the course). Plus deployment is to Heroku, so I'm sure I'll have the opportunity to learn how that plays into keep these sensitive variables a secret.

Prevent .env from being committed

Last step here is to add .env to .gitignore.

Set up config

If you need it, grab config here.

For the MERN course it's instructed to have a config/default.json where the MongoDB URI is stored. With the problem of not being able to access process.env inside it, that led me to custom environment variables via config.

Create custom config

Create a custom-environment-variables.json file inside the config folder. Paste the variable as a string into the JSON value field for the key. Then you'll be able to access it from your code via const db = config.get('mongoURI');



{
    "mongoURI": "DB_ACCESS_KYLE123"
}

Note: Custom environment variables take precedence over all other configuration files and will overwrite them. Only command line options can take top precedence.

Hopefully this has been helpful to you in either working with the MERN course or in your own personal or company project.

Thanks for reading!

www.kylewcode.com
Reach out to me on Twitter @kylewcode

2020 Retrospective: What I'll Keep Doing & What I'll Change

Kyle Williams — Sun, 10 Jan 2021 17:29:18 +0000

Since I started my programming journey in November of 2019, the bulk of my time learning was spent in 2020. I've been blessed to have avoided certain hardships from the pandemic and for that I'm grateful.

So naturally this really aided the process of learning programming in as relaxed manner as possible. As always, when looking back I can always have judgements about what I did well, what I did poorly, and everything in between.

What I'll Keep Doing

Being active in my community's Slack channel

By far this has been part of the 20% that gives 80% of assistance for my learning. Specifically this is the Orlando Devs (ODevs) Slack channel. I am very grateful for the time people have put into responding to my posts.

Calling my mentor around once a month

For any big decision, such as what programming path, framework, or language to learn, I run it through my mentor. I can get dozens of opinions from ODevs, but it's really essential to give more weight to one individual's advice, not because it's going to be correct but because it prevents hesitation and doubt. Hesitation and doubt increases stress levels and inhibits learning. For myself, it's better to act sooner than later than to bounce around in uncertainty.

Listening to TechJR

I find this podcast interesting because most other podcasts I listen to have been around for a while and are run by people who have generally been in their industry for a long time. Here I can hear a perspective that's a bit more relatable since the hosts have only been developers for over two years (at the time of this post).

Listening to Douglas Crockford

My mentor recommended I listen to Douglas Crockford mainly, in my opinion, because he's opinionated and older. I appreciate his candor and the larger perspective he has because of how long he has been around. Particularly I connect with his statement that programmers are emotional just like everyone else and don't necessarily make decisions based in logic. He often cites the slowness of innovation in software for this. To paraphrase him, "We have to wait for the older generation to die off to get adoption of newer, good ideas."

Maintaining a goal document in Evernote

I have a goal to obtain employment as a front-end React developer. I keep a document in Evernote where, with help from my mentor and one other ODev member Vincent Tang, the steps to get there are laid out in order. It's essential to have some kind of plan. The reality is that my plan changed a lot and therefore this document needed to be modified.

Organizing projects in Workflowy

I really like this app. It makes it really easy to go on tangents and drill down into whatever specific point I might be at. I use it to organize the TODO list for an application as well as writing pseudocode. It's so easy. When I encounter a problem I go down another level and split the problem into two more bullet points named PROBLEM and SOLUTION.

Work 25 minute spurts with 5 minute breaks

I work in 25 minute spurts because I think it's more effective for long term productivity but also so I can give my eyes a break (I have myopia).

Scheduling tweets to buffer

This makes it really convenient to come up with some things to say on Twitter in an hour or two sitting and have them queued up for weeks.

Keeping an engineering daybook

I got this idea from a post here by German Gamboa. Basically you write down something you learned in the day of programming. I keep it to things that are not 'too' mundane. Think of it as a journal of TIL (Today I Learned).

What I'll change

Commenting frequently on Twitter

I'm not a fan of social media, but Twitter is a busy spot for conversations around development. I understand the necessity of getting involved in the conversation. For me though, my focus is to be really clear on why I'm on Twitter and not move my attention to topics that are distracting or inciteful. So the goal is to be more active in commenting on other conversations. The main point is daily.

Not working past the point of my head hurting

I'm not very good at this. Since I put an arbitrary number on hours per day I want to study, which isn't necessarily a bad thing, I tend to push on even when I could lie down for a bit.

Not considering a lot of advice/opinions

Since I follow the self-taught path, one of the biggest traps is considering too much advice. I notice I'm in this trap when I start to have feelings of frustration and confusion. I have to exercise the courage to cut-off additional information and realize it's not going to matter in the long game.

Not going to bed earlier

I've already been a big stickler on sleep. The difference in my cognitive abilities, heck...everything, between the days I sleep well and don't is huge. If I could optimize anything right now it would be to get the best sleep possible. I have to wake at 4am for my day job so my bedtime is 8pm which I usually hit the sack at 8:15-8:30pm. Last night I crawled in at 7:20 and slept great, so probably doing that more might help. Overall I think I'm still too dumb to realize the false economy in programming while fatigued.

Not focusing on personal projects

I've spent a good bit of time on tutorials, algorithm challenges, etc in 2020. For 2021, after I finish some courses on React, I plan on spending the majority of time creating projects to go on my resume.

And that's it! Let me know in the comments below 3 things you will keep doing and 3 that you'll change. Good luck in 2021!

20 Lessons I Learned From Creating My First React App

Kyle Williams — Fri, 04 Dec 2020 21:38:58 +0000

Before I begin I just want to make it clear that what I write may not be true and only be applicable to myself based off my personality, background, temperament, attitude, etc.

Lesson 1: Web development is complicated, so be ready to get confused.

Complexity creates confusion - (paraphrased) Douglas Crockford

There is a lot to learn and being self-taught means that the most important decision to make is "What should I learn/focus on next?"

Documentation isn't enough because I've noticed that authors have to assert some level of prior knowledge on account of the reader. I heard Douglas Crockford say something along the lines of "Complexity creates confusion.", and web development is complex. It's the most complex thing I've endeavored to learn, which leads me to the next lesson...

Lesson 2: A mentor helps a lot.

One of my favorite books is Mastery by Robert Greene which illustrates a medieval apprenticeship model of learning that I prefer.

Luckily I have a friend who is a senior developer who is willing to lend his advice. Because web development is complex, it's much easier to just say, "My goal is _____. What should I do next?" Otherwise it's easy for me to waste time anguishing over what path to take.

Note: I have no preferences on any specific tool, language, or path. My friend suggested front-end web development based off my prior arts/music background. Others may be different.

Lesson 3: Don't get advice from too many people or sources.

Again, complexity creates confusion. Confusion has a negative impact on learning and productivity. In my experience it's better for me to make decisions from limited information without dragging it out and learn to live with the outcomes.

I may ask questions in huge forums, like Twitter, but I think it's better to limit the advice I consider.

Lesson 4: Don't spend too much time testing.

Testing got pretty difficult when I started to look at mocking data from API calls. It did not seem simple. I got advice from Vincent Tang to not spend too much time with testing. Back to lesson 3, I didn't ping 15 other people. I just stopped with testing as I had already learned the basics of Jest.

Lesson 5: Having so many different tools makes it easier to seek a solution in the wrong document.

Using create-react-app as a beginner, having made no React app prior, meant that I wast starting out with more tools. For example there is React.js, create-react-app, testing-library, jest-dom, and Heroku for my deployment. They all have documentation on certain aspects of development.

More importantly, I had no prior-experience with any of these tools.

For example, I found myself looking up deployment details on Heroku for Node.js apps. Later I learned there was different information from the create-react-app developer documents about deploying specifically to Heroku.

This caused confusion for me. The app seemed to build okay following Heroku's docs, but it wasn't clear which way was better or if it even mattered.

Lesson 6: Headaches are a sign I'm in over my head.

Jest's documentation on mocks was painful for me to read. I found myself not having the necessary prior knowledge to understand them.

I felt irritation, frustration, and pressure in my skull. This is not a good mental state for learning and waste of time. This is part of the reason I took a step away from testing.

Lesson 7: Programming -ahem- informs me if I am not clear on some prior foundational concept.

This is related to lesson 6. Bugs and sore eyes are the result. Time to move a level down.

Lesson 8: Sometimes the hardest decision is what to do.

I think I'm repeating myself? Web development is complex. It's important to me to know when to cut myself off from considering options and move forward.

My mentor suggested I just go to the school of hard knocks. There is nothing wrong with making mistakes. It's how I learn.
"Not doing that again. Jeez."

Lesson 9: It's easy to get lost in details and forget the big picture.

100% this being my main weakness. This is why feedback is critical for me. I have to tell someone what I am doing.

Lesson 10: People are capable of change.

By default I'm very methodical in learning and doing things. As I've become less afraid of failure, I'm noticing that with learning web development I'm a bit more 'jump right in' than I've typically been in the past.

Lesson 11: Don't run `npm init` with `create-react-app`.

This added entries to package.json that broke \%PUBLIC_URL%\

Lesson 12: Consider leaving configuration alone.

I tried following the install instructions for eslint configurations of react-testing-library and jest-dom. I just broke stuff and things didn't work. David K Piano suggested I leave the configs alone. That made things simpler and easier, which I learned later is the purpose of create-react-app.

Lesson 13: Check that the API serves over `https://`.

In the end I was unable to get my app fully functioning in deployment because of a "mixed content" error. I chose to drop an entire feature so I could finish and move on. Doh! This is what I'm talking about when I say "The harder the mistake, the better I remember."

Lesson 14: Having generalized project action steps would be great, thanks.

This is again about being clear on next actions. I'll be spending some time researching and creating a general project checklist template with a focus on keeping it simple, ie. no complicated project management tools.

Lesson 16: Starting a project from the basis of a tutorial can result in not being able to do something important later on.

I learned React first on FreeCodeCamp.com around the end of 2019. It teaches class components. My official decision to learn React is recent and someone suggested Kent C. Dodds' free beginners Egghead.io course on React using function components and hooks.

This course focused on CDN links to deliver react and react-dom with all of React happening in index.html as a static web page. Even though in the end I did not figure out how to protect my API key I did run into the problem that I could not access process.env within a static html file.

Lesson 17: Mocking an API call is hard and beyond my level right now.

There is a huge gap in my knowledge on how to make this work. My impression is that it has to do with understanding and manipulating back-end code. Knowing where I lack is a good thing because it tells me where to focus next.

Lesson 18: API integration may be good to be done before front-end code is built.

It felt clunky to be figuring out API proxy servers and such after having already built the front-end.

Lesson 19: Protecting API keys is not a simple task in React...at least right now.

Again, I think this has to do with my lack of knowledge in back-end coding since setting up a proxy server seems to be the solution.

Lesson 20: Creating a React app with a need-to-know strategy is okay.

There are many ways to learn. My default for learning has been to follow courses and tutorials top to bottom. Sometimes for me (not speaking for others), doing courses and tutorials too much is a sign of a fear of failure or making mistakes.

In this sense, learning piece-meal has been valuable on a personal level.

Thanks for reading!

If you're interesting in giving me feedback on my project I'd greatly appreciate it. You will find a working version, minus the API feature, on the codesandbox.

DEV Community: Kyle Williams

How To Efficiently Update React State For Multiple DOM Inputs Using the useReducer() Hook

Efficient VS Inefficient

Inefficient

Efficient

Gotchas

Further Cleaning

Connect With Me!

The Watch and Code Intro Part Is Unlike Any Other Programming Course I've Taken

The Meta-Skill of Problem Solving

Using the Debugger

Autonomy

Expectations vs Reality

Expectation

Reality

Slow is Fast

Setting Up Custom Environment Variables Using dotenv and Node-config

The Problem

The Solution

Set up dotenv

Add the environment variable

Note

Prevent .env from being committed

Set up config

Create custom config

2020 Retrospective: What I'll Keep Doing & What I'll Change

What I'll Keep Doing

Being active in my community's Slack channel

Calling my mentor around once a month

Listening to TechJR

Listening to Douglas Crockford

Maintaining a goal document in Evernote

Organizing projects in Workflowy

Work 25 minute spurts with 5 minute breaks

Scheduling tweets to buffer

Keeping an engineering daybook

What I'll change

Commenting frequently on Twitter

Not working past the point of my head hurting

Not considering a lot of advice/opinions

Not going to bed earlier

Not focusing on personal projects

20 Lessons I Learned From Creating My First React App

Lesson 1: Web development is complicated, so be ready to get confused.

Lesson 2: A mentor helps a lot.

Lesson 3: Don't get advice from too many people or sources.

Lesson 4: Don't spend too much time testing.

Lesson 5: Having so many different tools makes it easier to seek a solution in the wrong document.

Lesson 6: Headaches are a sign I'm in over my head.

Lesson 7: Programming -ahem- informs me if I am not clear on some prior foundational concept.

Lesson 8: Sometimes the hardest decision is what to do.

Lesson 9: It's easy to get lost in details and forget the big picture.

Lesson 10: People are capable of change.

Lesson 11: Don't run npm init with create-react-app.

Lesson 12: Consider leaving configuration alone.

Lesson 13: Check that the API serves over https://.

Lesson 14: Having generalized project action steps would be great, thanks.

Lesson 16: Starting a project from the basis of a tutorial can result in not being able to do something important later on.

Lesson 17: Mocking an API call is hard and beyond my level right now.

Lesson 18: API integration may be good to be done before front-end code is built.

Lesson 19: Protecting API keys is not a simple task in React...at least right now.

Lesson 20: Creating a React app with a need-to-know strategy is okay.

Thanks for reading!

Lesson 11: Don't run `npm init` with `create-react-app`.

Lesson 13: Check that the API serves over `https://`.