Thanks Chris! I made the correction. However, now that I reread the loading order docs, I'm conflicted if this is accurate. https://nextjs.org/docs/basic-features/environment-variables#environment-variable-load-order Again, I don't use this feature often so I hesitate to dig further at the moment. I tend to explicitly add the NODE_ENV to my command line args when running the prod build locally but it might be redundant in that next dev is implicitly NODE_ENV='development' and next start is NODE_ENV='production'. I'm tempted to see what NODE_ENV='development' next start produces. I'll have to try it out later. Anywho, thanks again for commenting and I'm glad these articles are still helping folks out after 2 years.

Thats awesome! Just in time to start writing again!

One thing worth noting is that the HEX color representation is an abstraction of actual color. There are other color representations such as 48-bit color that can represent 281.5 trillion colors and CYMK that uses a 4 dimensional vector. All of these are simply abstractions of the visible light spectrum. Also, the cones in eyes can generally distinguish 100 shades. Color blind people, typically only have 2 types of cones and thus can distinguish 10,000 colors (100x100). Most people are "trichomatic" meaning they have 3 types of cones and can thus distinguish 1,000,000 (100x100x100) colors. This is a far cry from the 16 million colors that can be represented with RGB. Although, some people (women exclusively) have an extra cone that allows them to see a wopping 100,000,000 colors. These people are considered "tetrachomatic".

Update: In the handleSuccess callback I added a few lines stop the stream. It was a little disconcerting navigating to a new page and having the camera light still on. stream.getTracks(). forEach ( function ( track ) { track.stop(); // e.g. turn camera off, etc }); In a future version, I'll store the device stream in a ref and run similar code when unmounting the React component.

Today I discovered that the "Rewrites for Static Files" section of this post is not necessary in the above case of robots.txt When I migrated to the the version of Next.js that introduced the public folder, I simply wholesale moved the static folder into the public folder. However, Next.js will attempt to serve files from public folder at the root url of your application. As such, you simply need to move the favicon.ico and the robots.txt into the /public directory and not bother with the rewrites. As an additional test, I added a file to the public directory that would conflict with one of my dynamic routes and Next catches it, which is pretty great.

That makes sense. I would really love for a native Firebase/GCloud solution as that is the ecosystem I work in even if it requires maintaining a separate dataset in a different FB/GCloud product. This is how I utilized Search API with Datastore for Gen 1 AppEngine.

Is adding full text search functionality to the Firebase product suite on the product roadmap?

Good article. It might be worth mentioning Symbols are also allowed. I've only run into them as object keys in some Google cloud libs. The only reason I like them (conceptually) is that they're harder to manually re-create when constants should be used since each instance is unique. I believe this is their explicit reason for existing.

Django is a framework and thus you have a lot of builtin functionality, which can be restrictive if you need to stray from what the framework prescribes. Node.js is simply the runtime like "Python" or "Php". Without leveraging frameworks written to run on Node (just as Django is a framework written to run on Python), you have the freedom to build from scratch, however cumbersome that may be. I have not kept up with Django since it's 1.2 release many years ago, but I remember working with their Data model a pain if you needed to use a NoSQL database, for example. Also, I found signals fairly annoying to work with. These things may no longer be an issue. Django was one of the more complete (and thus complex) frameworks I've ever worked with and I have not run across as robust of a framework for Node.js If you are writing python and just need a REST api to serve data, I have been enjoying working with Fast API with Pydantic typing. It would be comparable to running Fastify or Next.js API endpoints with TypeScript on Node.js.

Since a JSX React component is just a JavaScript function under the hood, much like a JS function, you can assign it to a variable. Then you can call it by reference. The function isn't evaluated at assignment time, but rather at call time. In JSX, the act of wrapping it in the angle brackets implicitly calls the underlying function. Contrived untested example: let myFunc = Math .add; // Not evaluated yet if (condition) { myFunc = Math . multiply; // Still not evaluated yet } return myFunc(...args); // Only now evaluated. Similarly, for JSX let MyComponent = Button; // vs. <Button /> if (conditional) { MyComponent = CustomButton; // vs. <CustomButton /> } // No components have been evaluated yet ... Do lots of other stuff // Component only gets evaluated below return < MyComponent { ...props } /> Note: JSX treats variables that start with lowercase names as html element names rather than variables and will error if it is not valid element. I have no idea what this does off hand, but it probably errors // let a = MyComponent // return <a {...props}> I ended up refactoring the table cell renderer code to leverage this concept and conditionally assigned the className and built the props rather than conditionally rendering the JSX.