Let's kick this short one off with a little thing you may or may not know, but you definitely should know. The 

 function identity does not change on rerenders. What this means is that you can (and should) omit 

On to the main topic. For this post I'm gonna roll with the tried and true Todo List example. We have a list of 

s and let's say we can have a bunch of them. Since there can be so many of them we wrap each 

 so that each one only rerenders when its own props change.

Furthermore, each todo item can be cloned, so each 

 that makes such a clone of an existing todo item. The cloned todo is appended to the 

function TodoList() {
    const [todos, setTodos] = useState([])

    const handleClone = useCallback((todo) => {
        setTodos([...todos, cloneTodo(todo)])
    }, [todos])
    
    return (
        <div>
            {todos.map(todo => (
                <TodoItem key={todo.id} todo={todo} onClone={handleClone} />
            ))}
        </div>
    )
}

Uh oh, users have started reporting that their todo lists are really slow, particularly when cloning todo items. What happened? We wrapped our 

, so why are they all rendering? Well, one of the props of 

 for that. And... oh, one of the dependencies of 

 state changes every time we clone a todo (because we add a new todo to the array). So cloning a todo rerenders 

const handleClone = useCallback((todo) => {
    setTodos(currentTodos => [...currentTodos, cloneTodo(todo)])
}, [])

 does not need to be added to the dependency list. So now this new version of 

 doesn't have any dependencies and its identity remains stable throughout the lifetime of the component! Now whenever we clone a todo, that new todo is added to the list without rerendering the already existing ones.

If you want to see these examples live, check them out here:

Little React Things: Cleaning up dependencies

Back when React Hooks first came out, the 

 was introduced and many like myself were like "great, a utility to react to things changing and keeping things in sync". And that is partially true, but it's not as simple as that. The new React docs that are under construction are more explicit about how and how not to use 

Even with the guidance from the new docs, these 

s still tend to pop up in the wild. They can be more than just unnecessary, and actually problems that should be fixed.

Let's say we have an app where a user can buy clothes, but instead of picking out each individual article of clothing, they can pick a bunch of articles of clothing that they like and set a price. Then the application shows the user a bunch of outfits that fit the chosen parameters.

The parent component of the app is where the user can pick the different pieces of clothing from the main list. Then there is a child component, 

 that lists all the outfits that fit the parameters.  This list of outfits is generated by a very cool helper function called 

; it's not an outrageously expensive function, but we definitely don't want to call it each time the 

 is rendered (this kind of function would not be done in the browser typically, but this is a React post, so here we are).

Let's take a look at a way we could create this 

function OutfitList({ clothingItems, maxPrice }) {
  const [outfits, setOutfits] = useState(null)

  useEffect(() => {
    const createdOutfits = createOutfits(clothingItems, maxPrice)
    setOutfits(createdOutfits)
  }, [clothingItems, maxPrice])

  return (
    <div>
      {outfits ? outfits.map(outfit => (
        <Outfit key={outfit.id} outfit={outfit} />
      )) : null}
    </div>
  )
}

 set up to react to changes in the clothing item list or price limit and recreates the list of outfits and updates the 

 in sync. All good? Well, there are a couple of issues with this solution.

Hold up, but it's called "React", what do you mean reactions aren't a good idea? Well, the reacting that we 

 want is reacting to user actions primarily and also asynchronous events. Code that synchronously reacts to your own code, on the other hand, is not desirable.

 runs after the render. So, for the first render we have populated 

. The state is out of sync for that first render which is no good. Our components then need to be made in such a way to account for these discrepancies. For example, we need to add a check to see if 

Furthermore, in the last post, I gave the guidance to not call the 

 is calling that function immediately after it is first called. So instead of one render, we will always have at least two renders each time either 

 are state in the parent component. Given that, we have three states: 

. But are those three states actually representing different things? I would argue no. 

This isn't good, state should be a source of truth. But here we have 

 as state, so which is the source of truth? From the user's perspective, I would probably say it's 

Why is this important? Well, what if down the road a developer is going to add a feature where the user can add a new outfit to the outfit list. The correct way to do this would be suggest some outfits that include a piece that weren't in the 

 list or that was a slightly higher price than 

 and then if the user picks one of those outfits, adjust those states accordingly. But this developer could see some state called 

 and simply just append a new outfit to that list. Uh oh, now we're really out of sync. We have a list of outfits that could 

 or that is a higher price than the price limit. This example is a little contrived, but I hope you get the point at least.

function OutfitList({ clothingItems, maxPrice }) {
  const outfits = useMemo(() => {
    return createOutfits(clothingItems, maxPrice)
  }, [clothingItems, maxPrice])
	
  return (
    <div>
      {outfits.map(outfit => (
        <Outfit key={outfit.id} outfit={outfit} />
      )}
    </div>
  )
}

 have values of course), we aren't immediately re-rendering after the first render, and we are still only calling 

So there you have it, with one technique we followed all three guidelines from the last post, we reduced the number of function calls (renders), simplified the parameters (state), and used memoization. Until next time!

Little React Things: Less reacting, more deriving

This is the first post of the Little React Things series and lays the foundation for the posts to follow. Consequently, it will probably be the longest post of the series, so hang in there!

What are React applications? A React application is a React component that is often made up of smaller React components. What is a React component? It's a function. Then according to the transitive property, a React application is a function. Hooray logic.

Just a note, when I say "React state", I'm talking about 

 the React state in your application, from all your uses of 

, or your favorite state management library (or your least favorite).

If we were to take a closer look at the body of such a function 

function f(x) {
	return (
		<div id="my-react-application">
			<h1>Hello, {x.name}</h1>
			{f1(x)}
			{f2(x)}
			{f3(x)}
		</div>
	)
}

 are various React children components (with bodies that can also look like the code above) of this component.

 changes. Whenever the React state changes, the function is "called" and a new UI is returned. Now, technically, if a piece of state is only scoped to a child component (like let's say 

 in the code above), React is aware enough to call just that sub-function and not the whole thing.

In other words, are React applications "pure functions"? No, they are not. They can be! But usually are not. Though state changes are the only thing to cause the function to be called, there are other things outside React state that affect the resulting UI. The resulting UI could be affected by the browser window size, the current time, or even just a random number generator.

If React applications are functions, then it follows that guidance for writing good functions applies to writing good React applications (more logic!).

Call the function as few times as possible

Calling the same function over and over and over again obviously can cause performance issues in any kind of system. Furthermore, the more you call the function, the more opportunities you are creating for that function to fail.

. You'll want to make sure you write your function in such a way that it works gracefully with whatever number the user passes in. They could pass in a positive number, a negative number, or even zero - not too many options to worry about there.

Now let's say you have another function, 

. With two parameters, you need to be even more careful how you write this function. This function needs to work gracefully if 

 is negative, if they're both positive, if one is zero, or if they're both zero. You've potentially increased the complexity just by adding another parameter.

The same applies to your React state, the more complex your React state, the more complex your React components need to be in order to render a reasonable UI given all the potential permutations.

React has a built in higher order component for performing this technique, 

. Memoization like any technique is not a silver bullet. Like anything in software development, there are tradeoffs. When and how to use 

 could be a post on its own, in fact it often is. One that I recommend is 

Use React.memo() wisely (dmitripavlutin.com)

I hope to provide practical React tips to apply these guidelines in the following posts of this series. So, stay tuned!

Little React Things: React applications are functions

 back in 2016, I have always had a fondness for static site generators. I have always enjoyed trying new things, and so far have never used the same static site generator twice. I made my first personal site with Hugo, I made a video game idea website with 

. Wait, no I actually used Hugo twice - another time for the website for 

 and then remade my personal website with 

Which brings us to this site, my third personal site. This one is made with 

 for a CMS. I'm feeling good about this one. I think the reason I bounced around so much is that early in my career I didn't feel like I had any particular proficiency in any web technology; my first four years out of college were at a job writing 

 was getting popular at the time and that's how I found Hugo. Fast-forward to now, and I have several years of 

 under my belt and feel very at home in front-end development.  

With all the React experience (and I also really like it) it seemed like Gatsby and Next.js were the two obvious choices. Don't ask me why I last remade my website with Sapper, that was just a bad idea (it's not a bad tool, I just don't know 

). Well, I had already tried Gatsby, and I didn't like it. I don't think I care for 

 (but I've also never really tried to learn it, so 🤷‍♂️). So, I decided to try Next.js this time around. I've barely used it enough to give it any sort of review, so - I won't do that.  

This website

If you are developer chances are, if you are on your computer, you
have a web browser open. And there's a solid chance that it's Chrome. If so, this is for you.

By now, many of you know that you can set up custom search engines to use in
Chrome's Omnibox, they're super handy. If you know how to set one up, skip down
a paragraph; if not, here's how: In Chrome, go to 

.
Here you can define custom search engines that have three properties: a name,
an alias, and a URL. For example, I have a custom search engine called Wikipedia,
with an alias 

http://en.wikipedia.org/w/index.php?title=Special:Search&search=%s

 will be replaced by the search string. If I want to search
Wikipedia, all I have to do is, in the Omnibox, type 

 (space or tab) and
then the search string (whatever I want to search for), and bam, it is searched.

Now, being able to search websites easily through the Omnibox is well and good,
but let's try thinking outside of the (Omni)box. I will share with you some of
my favorite custom search engines, and why they are great (or at least neat).

5. Translate (for me, English to Spanish)

https://translate.google.com/?source=osdd#en/es/%s

 is the "to" language.
I would rank this higher if I used it more, but still, handy in a pinch! I'm sure
you could do the same with another translating service.

https://www.merriam-webster.com/dictionary/%s

Obviously, use whatever dictionary website you want. Once I set up the thesaurus
search engine, I find that I use it a surprising amount! And now I write illustriously.

I use a lot Atlassian products, like Jira and Confluence, and I've set up a custom
search engine for Confluence, and one search engine for each Jira board I'm
interested in. If you or your company has some sort of intranet site or wiki or
online documentation, a custom search engine works like a charm.

 as the alias, so I can type "maps Chipotle" and will immediately be
shown the nearest Chipotles, which is cool, but we can take it a step further.
I can also type "maps here to Chipotle" and I will be given directions to the
nearest Chipotle. Technology at it's finest. Furthermore, if you have your home
or work location set with Google Maps, you can type things like
"maps work to Chipotle" and be given directions for that.

https://www.google.com/search?q=%s&tbm=isch&tbs=itp:animated

You want to be the fastest gif in the West? This is how. Call me old-fashioned,
but I prefer Google's animated image search over Giphy, especially at work. I
mean, the last thing I want is a bunch of flashing colors and images on my screen
to draw attention to the fact that I'm looking for a gif.

Amazon, YouTube, Google Calendar, Bible Gateway, Spotify

How's your Omnibox game?

One thing I did not realize when I started my career as a software engineer was how much time would be spent investigating issues and fixing bugs. At my current company, my teammates and I take turns being the point-person for production issues and support tickets; it's not my favorite shift, but it needs to be done.

Being responsible for several issues and bugs can be quite overwhelming, especially if you bounce between several support tickets multiple times a day. Over the past few years, I've adopted several practices that I've found helpful, and maybe they can help you too!

It sounds obvious, but organization is can drastically improve your efficiency as a programmer. When returning to work on a ticket in the morning or after a weekend or after working on something else, we want to spend less time asking "what was this all about again?" or "how far along was I in this?" and more time fixing the problem. Here's how I like to stay organized.

I like to have a folder that contains a folder for each ticket I'm dealing with that shift. Each folder is labeled with the ticket number and a brief description (usually the title of the ticket). In each folder, I keep any data files that I may have copied from one of our file servers. If I have taken any notes that don't need to shared on the ticket itself, I'll keep those here too. Lastly, I keep a SQL file here (more on that later).

An extra note about files: if you are investigating a data issue and you have a set of files that have good data and some that have bad, clearly label them GOOD and BAD. It sounds obvious, but I've only just started doing this, and it really helps. The less you have to access the hard-drive that is your long term memory, the faster you work. More significantly, there's nothing worse than scrutinizing a file thinking it's a bad file when, in fact, it is not.

Similar to our filesystem folder, it is good to have a clearly labeled bookmark folder that has bookmarks to any and all pages relevant to the ticket. Links to reading material, Stack Overflow questions, and documentation are all valuable items to preserve. If you are working on a web application, bookmarks to the pagesof issue are very handy as well.

Lastly, I like to have a SQL file that contains any queries that I use in my investigation of the ticket. Personally, this has been the most helpful practice of all. When jumping back and forth between tickets, I found that I was having to recreate certain queries each time to catch up to where I was before. This is an absolute waste of time. If you have any queries that aren't obvious in their function, slap a comment on them; you may remember what they do now, but you might not after a long weekend.

You want to find an optimal balance between asking for help and figuring it out yourself. In my experience, that balance is found in asking for help more often than not. What I mean by "asking for help" is not asking someone to solve your problems, but rather to point you in the right direction. If you are afraid that you are bothering your teammates, remember, it's better to spend 15 minutes of both of your time figuring something out than you banging your head against that problem for an hour. If your teammates have been in the game for awhile, I'm sure they understand this.

Your fellow engineers aren't the only people who can help you in fixing issues. If the issue was reported by technical support or customer representative; make sure to chat with them about anything ambiguous or unclear in the ticket. Avoid wasting time solving the wrong problems.

If a client is reporting behavior in your application as a bug or issue, and tech support sends it up to you, but it turns out the application is working as intended, or the issue is due to customer error; be gracious in your response.

 make the tech support person or client feel dumb for not realizing this.

 use this as an opportunity to reevalute your application to see if there are ways to prevent this issue from happening again.

If you aren't interfacing with customers directly, someone else is, and they are probably the person who reported the ticket. Be conscious of the pressure this position can bring. Be quick in your first reponse to a ticket; if there's any information you can give immediately, provide that as soon as you can. Also, keep them posted on any updates; you don't want your customers to feel like you aren't working on their issue. Furthermore, if there is a tech support / customer support manager, talk to him or her to see if they have a priority list of which issues should be addressed first. It can be tempting to work on issues that appeal to you, but that is not helpful for your team. Trust your support teams to accurately gauge the feelings of the customer.

In larger engineer teams, it's hard to know the ins and outs of every software component. When you are done investigating and resolving an issue, document it. If you found yourself debugging an poorly documented system, fix that! Don't let the next developer have to go through the same thing as you. You can both document this in a permanent place where your teammates can easily find it, but also I'd encourage just sending a message to your teammates saying something along the lines of "Hey all, I just was investigating 

, let me know if you'd like to hear more about it."

Okay, that's all I got. I hope you find at least some of this helpful. Now go put out those fires!

Handy tips for software support

Each day the value of a portfolio can either rise or drop a certain percentage. Now,
let's say you have a list of the daily returns since the inception of the
portfolio and you want to find out what the portfolio's returns over several
date-ranges are. Most likely you'll want to know the daily return, the
week-to-date return, month-to-date return, and so on, up to the
inception-to-date return.

To calculate the time-weighted return from inception to a certain end-date,
one would need to do the following:

 is the daily return after the inception date, and R

 is end-date's daily return. So we have to iterate over this list of daily returns multiple times in order to calculate all our returns, right? No. You see, the above formula doesn't just work for daily returns, but rather returns over any arbitrary, consecutive periods. So if you have a return for the month of  April and one for the month of May, you could do the following:

and you would end up with the return over both months. You see where I'm going
with this?

First things first, we need to get our dates straight. We need our end-date that
we are getting returns for, we need the inception date, the last day of the
previous year/quarter/month/week (in regards to the end-date), and the day
before the end-date. We'll call these dates our breakpoints.

Okay, so we will store our daily returns in an array, sorted by date, ascending.
We will translate our date breakpoints into indexes into that array by
subtracting the inception date from those dates.

. Now this is where the
memoization comes in. The first thing 

 does is check a map
to see if this date range has already had a return calculated for it; if it
does, it returns that. It then iterates from 

, adding
each daily return to the formula at the top. Once we iterate to a breakpoint,
we then call 

 and add that to our
formula. Essentially making the formula:

So, lets say we already calculated the daily and week-to-date return and we want
to  get the month-to-date return. We start by calling 

. It
will iterate from the last day of the previous month until it hits a breakpoint,
which will most likely be the last day of the previous week (if we aren't in
the first week of the month). It will then call


 and that call will find that we
already calculated that return and won't have to do any more calculations! We
then keep doing this for quarter-to-date, year-to-date, and finally,
inception-to-date, all without iterating over the same daily return more than
once!

It should be noted that if the inception date is more than a year prior to the
end-date, its return is probably most useful if it is annualized. This doesn't
really change our method above, it just tacks on an extra calculation at the
end.