Adding a Development-only Warning Logger

[00:00 - 00:10] To be a top-quality community hook, we should have a way to display warning messages to developers using our hook. Like many frameworks do, we'll only show these messages in development mode.

[00:11 - 00:23] To determine if the environment is development or not, we'll check the fairly standard node-env environment variable for its value. If node-env is development, we'll display a warning message to the user.

[00:24 - 00:46] We'll also prefix our message with use-please-stay and suffix it with "This message is shown in development only" to make it clear that the message is coming from our hook and will be shown only in development scenarios. Since this decision is slightly opinionated, since not all applications are built using a node-env environment variable, we'll make a note of this in the readme.

[00:47 - 01:28] So let's hop into our readme. And I'll just make a title here, "Warning Logs" and this hook will display various warning messages if the node-env environment variable is set to "development".

[01:29 - 01:56] These messages are a helpful reminder in development only and will not be displayed in production. Luckily for us in our example app, which is based off of Create React app, Create React app does make use of the node-env variable, so we still have a great way to test if our development only logger is working or not.

[01:57 - 03:14] So let's first create a utility function which I'm going to call issue-warning message, and we can put that right in the utilities folder. And for this function we'll be passing in a message, which is a string, and as we said, if process.env.node-env is equal to development, then we're going to console.warn, now let's add the message, and we said we would prefix this message to make it clear that it's coming from use, please stay, and also a reminder that it's shown only in development.

[03:15 - 03:32] We also noticed that TypeScript is complaining here and that we should install the node types. And with that installed, the error warning goes away, and now we can start actually using our warning message utility function.

[03:33 - 03:44] And so we know how we've designed the hook so far, there are a few edge case scenarios that we can warn developers about. We can collect all of these checks into a new function which I'm going to call validate parameters.

[03:45 - 04:23] So I'll put that also here in the utils folder. And so far all of our warnings will revolve around the titles array, which is a type of array of one or more string, and also the animation type, which is of type animation type.

[04:24 - 05:10] One edge case we've already briefly discussed is that if the title's length is only one, and that title is just an empty string, then we're going to use our issue warning message function, and we'll say you have passed an empty string as the title. This will result in no text being displayed regardless of animation type chosen .

[05:11 - 05:22] And we also know we have an edge case when the animation type is cascade or marquee. We know from our implementation that we only take the first title in the titles array.

[05:23 - 06:05] So I'm going to first check against the cascade case. So if titles.length is greater than one, and the animation type is animation type.cascade, then we'll again use our issue warning message function and say you have passed more than one title, but have specified animation type.cascade.

[06:06 - 06:37] Only the first title in the titles array will be used. And we can copy this entire block, paste it in here and modify the cascade animation type to the marquee animation type, also being sure to change what's sent to the logger.

[06:38 - 06:51] And we can format this and save, and we should be all set. And we can add this as the very first line in use please stay.

[06:52 - 07:02] So we'll call validate parameters and we'll forward on both the titles and the animation type. Now let's test our logger.

[07:03 - 07:19] You can build the app, move into the example folder and start the application. And what we'll do now is hop into app and of course we want a scenario which would cause one of our warning messages to be shown.

[07:20 - 07:37] So here we have two titles and I'll just pass the animation type of animation type marquee, and we expect we should see that warning message in the browser. And indeed we do see our warning message.

[07:38 - 07:45] You have passed more than one title, but have specified animation type marquee. Only the first title in the titles array will be used.

[07:46 - 07:53] And of course this message will be shown in development only. So the warning message function we've built looks great, makes a lot of sense, it's very clear.

[07:54 - 08:08] And we see that it's logged twice here, but we'll discuss why that is in the next lesson it has to do with how React runs in development mode. And to test that our messages appear only in development mode, let's build a production build of our app.

[08:09 - 08:21] So we'll do npm run build. We'll ensure that we have the latest version of serve installed with npm install -g serve.

[08:22 - 08:32] And we'll serve our production app with serve -s build. And so now that we're running in production, we of course do not see our warning messages.

[08:33 - 08:51] So in summary we created a function which issues a console warn message only in development. We utilize this function in another new function which we called validate parameters that validates some of the strange edge cases when certain values are passed to the hook.

[08:52 - 09:10] And we called this validate parameters function as the first line within use please stay. In the next lesson we'll create yet another warning message to help prevent developers from concurrently calling use please stay via a local storage variable.