You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.
Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:
Memoization means caching the output based on the input; in the case of functions, it means caching the return value based on the arguments.
Values and references are unfortunately overloaded terms that can refer to the low-level implementation details of assignments in a language like C++, for example, or to memory
Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
pathname - The "file/directory" portion of the URL, like invoices/123
search - The stuff after ? in a URL like /assignments?showGrades=1.
query - A parsed version of search, usually an object but not a standard browser feature.
hash - The # portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
Webpack 4 automatically polyfilled many Node APIs in the browser. This was not a great system, because it could lead to surprisingly giant libraries getting pulled into your app by accident, and it gave you no control over the exact versions of the polyfills you were using.
So Webpack 5 removed this functionality. That means you need to make changes if you were relying on those polyfills. This is a quick reference for how to replace the most common patterns.
List of polyfill packages that were used in webpack 4
For each automatically-polyfilled node package name on the left, this shows the name of the NPM package that was used to polyfill it on the right. Under webpack 5 you can manually install these packages and use them via resolve.fallback.
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
You're Missing the Point of Promises
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most
basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic",function(err,results){// the rest of your code goes here.
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.