<p>Over the course of the last couple weeks, I&#39;ve made some small improvements to my site. None of them are particularly huge, but I like the end result.</p>
<h2>Adjusted the Header</h2>
<p>I decided to change up the header a little bit. The header isn&#39;t horribly different from before, but now I decided to make it span the full width of the browser window. I also added a link to the RSS feed since I feel that&#39;s an important feature in today&#39;s web. It might have fallen out of favor in some circles, but I still love it. I also moved the light/dark mode switcher from the footer to the header and made it a little more descriptive with a sun and moon icon.</p>
<h2>Adjusted the Footer</h2>
<p>I also decided to adjust the footer, re-laying out the links and allowing it to fill the full browser window.</p>
<h2>Removed SASS</h2>
<p>SASS came pre-bundled with Jekyll so when I built the original version of my blog, it made sense to just go with it. Since then, CSS has gotten official variable support as well as a whole bunch of other nice features, so I decided to swap it out with plain old CSS. The conversion wasn&#39;t too bad and I feel like I was able to clean up the CSS some in the process, particularly with the light and dark mode.</p>
<p>CSS variables just make applying a light/dark theme so simple</p>
<pre><code class="language-css">:root {
    --font-family: &#39;Maven Pro&#39;, &#39;Segoe UI&#39;, Helvetica, Arial, sans-serif;
    --background: #ededed;
    --background-image: url(&#39;/assets/images/background.png&#39;);
    --font-color: #444444;
    --blue-medium: rgb(6, 44, 156);
    --blue: hsl(215.9, 100%, 40%);
    --box-shadow: 0 12px 24px 0 hsla(0, 0%, 0%, 0.2);
    --dark-grey: hsl(0, 0%, 40%);
    --review-border-color: var(--blue);
    --svg-display-lightmode: inline;
    --svg-display-darkmode: none;
}

@media (prefers-color-scheme: dark) {
    :root {
        --background: hsl(0, 0%, 13.3%);
        --background-image: none;
        --font-color: hsl(0, 0%, 93.7%);
        --blue-medium: hsl(209.1, 78.5%, 43.7%);
        --blue: hsl(199, 98.3%, 45.9%);
        --review-border-color: rgb(239, 239, 239);
        --svg-display-lightmode: none;
        --svg-display-darkmode: inline;
    }
}
</code></pre>
<h2>Changed the Light/Dark Mode Toggle</h2>
<p>Besides the switch itself, I also changed how I handle overriding the system&#39;s theme. The CSS variables definitely helped with this, although I have an item on my to-do list to see if I can&#39;t improve this a little more. If you&#39;re a user who overrides your system theme, there might be a momentary flash of the system theme before your override takes effect. It&#39;s still an option though so I feel like that&#39;s a plus.</p>
<h2>Started Working with SVGs</h2>
<p>SVGs were something that I only recently started looking at. I decided to go with SVGs for both the theme switch and the RSS icon at the top. Learning <a href="https://inkscape.org/">Inkscape</a> as well as how to integrate it into the page was a fun challenge.</p>
<h2>My &#39;Likes&#39; Page</h2>
<p>I used to run weekly posts with links I&#39;ve liked. I&#39;ve decided to take a page from <a href="https://daverupert.com/">Dave Rupert</a> and simply add a page that lists recent articles, podcasts, or anything else that catches my eye. I liked his idea of using his Feedbin starred feed, but felt like I might as well make it manually as I find things elsewhere that I&#39;d want to include. You can veiw this on my <a href="https://kpwags.com/likes">Likes page</a>.</p>
<h2>Updated Bookshelf &amp; Movies</h2>
<p>My <a href="https://kpwags.com/bookshelf">reading list &amp; bookshelf</a>, as well as my <a href="https://kpwags.com/movies">movies</a> used very similar code to render. I opted to condense the JS that handles them as well as the CSS to make the pages easier to manage. I also ended up shrinking the images and expanding the width some to allow more content to be viewed at once.</p>
<hr />

<p>I generally like how my blog looks so I didn&#39;t go hog-wild, but it was nice to &quot;freshen&quot; it up a bit. I have a few more things I&#39;m thinking of doing, but let me know what you think so far.</p>


Some Small Site Updates

<p>A little while back, I started a new project. I have been using <a href="https://kpwags.com/2020/01/21/tracking-my-fitness-journey.html">spreadsheets to track a lot of my fitness goals</a>. This approach generally works, but I thought it would be easier if I had an app for that. So I did what any self-respecting fitness enthusiast developer would do...make one myself! But with that, also come unit tests.</p>
<p>There are a whole bunch of options out there to track this stuff, but not all of them do everything, and they don&#39;t do what I think works for me. I also figured that I&#39;m a developer and I could build myself something that works for what I&#39;m looking for. I was also itching to try out Typescript &amp; React, as well as the .NET Core Web API.</p>
<p>Not to get too in the weeds, but with this project, I wanted to do unit testing as I develop rather than at the end like I did with Digital Family Cookbook. The one thing I realized that I needed to do was be able to mock the API calls on the frontend. I stumbled upon a great post by Kent C. Dodds talking about how we <a href="https://kentcdodds.com/blog/stop-mocking-fetch">shouldn&#39;t be mocking window.fetch</a>. In it, he talks about <a href="https://github.com/mswjs/msw">MSW</a>, short for Mock Service Worker and how we can use that to intercept and mock our data calls.</p>
<p>I decided to give it a try and I have to say that I&#39;m seriously impressed with how easy it is to setup and use. I figured I&#39;d spend a little bit of time here going through how to quickly set it up and how to use it.</p>
<h2>Install</h2>
<pre><code class="language-bash">$ npm install msw --save-dev
</code></pre>
<p>or</p>
<pre><code class="language-bash">$ yarn add msw --dev
</code></pre>
<h2>Setup</h2>
<p>I have a folder in my <strong><code>/src</code></strong> directory called <strong><code>test</code></strong> that holds my basic testing configuration. You can put these files in a different directory if you have your project laid out differently, but the handlers and the server setup are how your fetch calls get handled for your unit tests.</p>
<h3>Create Your Handlers</h3>
<p>MSW works by having a list of handlers that handle the various different fetch calls. You specify the endpoint and when window.fetch calls the endpoint, instead of interacting with your API, it interacts with the mock server.</p>
<h4><code>/src/test/server-handlers.ts</code></h4>
<pre><code class="language-javascript">import { rest } from &#39;msw&#39;;

const handlers = [
    // retrieve a user by their ID
    rest.get(&#39;*/users/getuserbyid&#39;, (req, res, ctx) =&gt; {
        const id = req.url.searchParams.get(&#39;id&#39;);

        if (id) {
            const userId = parseInt(id, 10);

            if (userId &gt; 0) {
                return res(
                    ctx.status(200),
                    ctx.json({
                        id: userId,
                        name: &#39;Keith Wagner&#39;,
                        email: &#39;testing@testing.comm&#39;,
                    }),
                );
            }
        }

        return res(
            ctx.status(400),
            ctx.json({ message: &#39;User does not exist&#39; })
        );
    },

    // save a user
    rest.post(&#39;*/users/saveuser&#39;, (_, res, ctx) =&gt;
        res(
            ctx.status(200),
            ctx.json({
                successful: true,
                user: {
                    id: 1,
                    name: &#39;Keith Wagner&#39;,
                    email: &#39;testing@testing.comm&#39;,
                },
            }),
        ),
    ),
];

export { handlers };
</code></pre>
<p>Let&#39;s take a look at this code. This is where you specify how each endpoint will respond to the API call.</p>
<p>Let&#39;s take a look at the first handler where I&#39;m getting a user by their ID. My React component might need to handle a situation where the user being looked up doesn&#39;t exist. In this case, I can add some logic in the handler to return an error in this case when the ID is less than zero. That way I can test how the component handles an unknown user by passing in a negative number (or zero), while returning the user&#39;s info for other requests.</p>
<p>Not all handlers need to be as complex. If you look at the second item where I&#39;m saving a user, you&#39;ll see that I don&#39;t have any logic around the request, I just send back a success message. Depending on what you&#39;re testing, you might not need to do any additional handling of requests and responses.</p>
<p>Just make sure to add a handler for every fetch call.</p>
<h3>Setup Your Server</h3>
<h4><code>/src/test/server.ts</code></h4>
<pre><code class="language-javascript">import { setupServer } from &#39;msw/node&#39;;
import { handlers } from &#39;./server-handlers&#39;;

// create the server object by passing in your handlers
const server = setupServer(...handlers);

export { server };
</code></pre>
<p>This code sets up your server by passing in the handlers you created above and passing them as an argument to the setupServer object from MSW.</p>
<h3>Setup Your Tests</h3>
<h4><code>/src/setupTests.ts</code></h4>
<pre><code class="language-javascript">import { server } from &#39;./test/server&#39;;

beforeAll(() =&gt; {
    // start up the server
    server.listen({
        onUnhandledRequest(req) {
            console.error(&#39;Found an unhandled %s request to %s&#39;, req.method, req.url.href);
        },
    });
});

afterEach(() =&gt; server.resetHandlers());

afterAll(() =&gt; server.close());
</code></pre>
<p>This code imports your mock server and tells it to start listening before running any tests, and then resets the handlers and closes the mock server when testing is complete.</p>
<p>When starting the server in the <strong><code>beforeAll</code></strong> function, I like to pass in the <strong><code>onUnhandledRequest</code></strong> argument. I sometimes forget about calls to the API when writing the tests, so if a window.fetch call is made that I don&#39;t handle, it will output an error message to the console letting me know what call was made so I can go back in and handle it. It&#39;s not necessary, but I&#39;ve found it useful now and again.</p>
<h3>Telling Jest About MSW</h3>
<h4><code>/jest.config.js</code></h4>
<pre><code class="language-javascript">module.exports = {
    setupFilesAfterEnv: [&#39;./src/setupTests.ts&#39;],
};
</code></pre>
<p>Jest needs to know that MSW exists so that it can start the listener. In the setupFilesAfterEnv array, make sure to add the <strong><code>/src/setupTests.ts</code></strong> file.</p>
<h2>Final Thoughts</h2>
<p>This is basically all there is to the setup. Anytime your frontend makes a fetch call, instead of going to the actual endpoint, it will instead go to your mock server. For me this makes this portion of testing easy as I can worry about unit-testing the API separately and focus primarily on the components and frontend. MSW makes configuring the handlers is simple and easy while still providing you the ability to handle edge case and error logic as needed. I would highly recommend giving it a try.</p>
<h2>One Last Thought</h2>
<p>One other cool thing about MSW is that you can also use it for development as well as testing. I can&#39;t really attest to it as I don&#39;t use it for this use case, but MSW allows you to setup a service worker to handle your requests as you develop. If you don&#39;t have access to your backend locally or don&#39;t want to play around with your database for whatever reason, you can <a href="https://mswjs.io/docs/getting-started/integrate/browser">set it up</a> to play the backend for your development work as well.</p>


RSS Feeds

Everything

Blog Posts

Reading Logs

Book Notes

Choose Color

Posts in February 2021

Some Small Site Updates

Unit Testing with MSW