DEV Community: Calie Rushton

What I learned last week (38/24)

Calie Rushton — Wed, 25 Sep 2024 08:33:23 +0000

Reactivity in vanilla JavaScript – use the Proxy pattern to fire events when app state changes. (Frontend Masters course - 'you might not need a framework')
throw new Error("Error!") cannot be used in a ternary (at least not as the 'else' part. The last part of a ternary operator must be an expression, not a function. 'throw' is not an expression, rather it's a statement used to interrupt execution of functions.
A 'stack' in Javascript can be considered a bit like an array, if used in the context of solving problems like you might find on Leetcode. It follows the Last-In-First-Out (LIFO) principle, where elements are added and removed from the same end. Stacks are used to manage function calls, undo functionality etc.
In Javascript any arbitrary number of arguments can be passed to a function. They are accessible via an arguments object which is 'array-like', ie you can use methods such as .length to see how many arguments have been used on the function invocation, for example. (This one is pretty fascinating and well-worth exploring in the console.)

Things I learned last week (23/24)

Calie Rushton — Tue, 30 Jul 2024 12:47:15 +0000

Oftentimes, if you are working in VSCode and encounter a typescript error that doesn't makes sense and you can't fix it, pressing cmd + shift + p and selecting "Developer: Reload Window" is enough to make it go away!!
Memory leak - "an unintentional form of memory consumption whereby the developer fails to free an allocated block of memory when no longer needed." In real terms it's like constantly buying new lip balms because you keep losing or misplacing the old ones. They're still out there somewhere!
CSS: Grid looks at the container of elements to determine layout, while Flex concerns itself with the individual element to determine it's behaviour - good to know for the mental model and understanding what might be some of the limitations of Flex depending on your use case.
Typescript: Discriminated unions - a union of different types which all share a common property - the 'discriminant'. The remainder of each type can be composed of different kinds of properties so long as it has the discriminant property, which might then be used as a condition in a function, for instance calculating the area of a shape type.

Mustard and serving hatches (or 'How I explain what I'm learning to my parents…')

Calie Rushton — Wed, 05 Jun 2024 11:12:06 +0000

I recently rediscovered a load of blogs I wrote during bootcamp in 2019. It felt good to retrospect and I'm also pretty proud of them, so I'll be reposting some of them here....

I'm 11 weeks into coding bootcamp and my mind is turning towards a subject for my next blog. This weekend is a little different from the previous ones - all the code challenges have been taken and passed, next week we continue working on our paired projects and then its onto the final module, the one where all our learning comes together in projects we will conceive and build by ourselves.
We have all written and given our Flatiron School Presents presentations. There are no labs to be done in preparation for a week of lectures on an entirely new topic. It feels like the first real chance to breathe since this whole intense experience began, a brief moment of calm before module 5 kicks off. Unsurprisingly my mood is somewhat reflective.

We had a presentation in our first module, a key theme of which was perspective. It is only after you've travelled a way down a road that you can pause to take a look over your shoulder to see where you've been, to look at the same place from the opposite direction and with the wisdom and benefit of hindsight.

I don't come from a computer-literate family, in the sense that lots of developers often seem to. In junior school we had a single BBC Micro computer in the classroom that we could take turns playing Podd on, then when the Gameboy came out me and my sister would spend hours playing Tetris and Super Mario Brothers, but I wasn't involved in anything deeper than switching a console on or typing 'Podd can jump'. I didn't have any idea what programming was or how the games were made but I did love breaking things apart and putting them back together, so I ended up becoming a car mechanic.

So when I found myself changing careers many years later, my family (and at first myself) were surprised at my choice but supportive nonetheless. (My amazing mum was still playing with my Mod1 CLI game way after everyone else had drifted out of the room.) Catching up over dinners at the weekend they say "so what are you learning at the moment?". I take a breath and think about how best to describe the stuff I'd just learned that week and wasn't even sure how well I understood it yet.

Explaining something to someone else is a great way to check your own grasp on a subject. It's one of the reasons we write blogs during bootcamp and beyond. I often need to relate what I'm learning to something tangible, which means my conversations with my family go something like this:

"I'm learning about how the internet works; what happens when you press a button on a webpage; how the front and back end interact."

"The what and the what?"

"Frontend and Backend? Well, you know when you come to ours for dinner, you all sit at the table and I'm in the kitchen still, and I usually stick my head through the hatch and ask you if you want any condiments? Well you're at the front end, the fridge is the back end, and I'm whats called a server. When you ask me for mustard, or click on a link to go to a new webpage, that's a request from the frontend, or the 'client'. You requested mustard so I have a look in the fridge, which is a database where all the condiments - or web pages (more specifically all the text, pictures and instructions for how to style them) are stored. Once I find it, I take it back to the hatch, stick my arm through and pass it to you… that's the job of the server - go get the thing the client (browser) asked for, and serve it up to them so it can be looked at on the computer screen. Or in your case, spread onto your steak."

There's also a story about what variables are and how (and why) we pass them, explained in the context of Mum and Dad writing the Christmas cards. I'll save that for another time.

When I realise I'm losing them, I adjust my approach but smile inwardly because I also realise that I'm getting it. The coding journey started for me when I went to my first Girls Code MK meetup just a year ago: I always thought coding was beyond me but within the hour they'd helped me display a picture of kitten, and I even knew how to change the colour of the border. I can't wait to go back there in a few weeks armed with my newfound knowledge, and perhaps use it to help another woman or girl get started on her journey. I might need to work on my stories though.

Things I learned last week (21/24)

Calie Rushton — Wed, 29 May 2024 08:06:16 +0000

Use git add -p instead of git add -a to view your changes in the command line. It's like a mini code review without leaving your terminal, very cool.
gh repo create is a command for creating a new repository in your github, to hold your newly-initialised project. After you hit enter you need to answer a few questions and 'voila', you can see the new repo in your github!
pnpm is the new npm. It's built on top of npm but is faster and more efficient.

Things I learned last week (20/24)

Calie Rushton — Tue, 21 May 2024 08:55:39 +0000

By default, all React components in NextJS are React Server Components, whereas in vanilla React, all the components are client components.
You can prove that a function (component) is being executed on the server by adding a console log, then checking in the terminal where NextJS is running. The log will not appear in the browser dev tools.
In NextJs the notFound() function will load the nearest not-found page to the component where it is invoked. To show a more specific message, create a not-found page next to that component.
It's a good idea to export types and interfaces from React components, so that the tests you write will be able to access them.

Things I learned last week (19/24)

Calie Rushton — Tue, 14 May 2024 08:08:31 +0000

In Typescript, a type object cannot be extended once it is declared, but an Interface can.
You can specify the type a function should return - insert the type after the argument parentheses: const makeUser = (): User => {}
CSS Modules are a really nice way to declare styles that are scoped only to certain component. This means you can use a class name more than once without fear of applying the wrong styles. Write styles in a CSS file in the same folder as your React component, the import it into the component.
React Router drastically reduces the amount of state management needed in an app. Because it handles the fetching of data you don't need to do this in a useEffect or implement an isLoading state

Nevertheless, I Code

Calie Rushton — Sat, 07 Mar 2020 11:34:11 +0000

Growing up I never really accepted that there were blue jobs and pink jobs.

While I knew about the traditional stereotypes as far as male and female job roles, I didn't really see that as a barrier for myself. I just thought "I want to do that, so I'm gonna go do it.". I was lucky enough to have parents who always told me I should do what made me happy, so when I announced I was quitting my degree because I wanted to become a car mechanic, they didn't try and put me off because it was a male-dominated profession.

I don't think cars were a passion for me as such; I enjoyed hanging around with my best friend while he modded his Nova back in the 90's, but for me I think becoming an apprentice vehicle technician was a way to indulge my passion for taking things apart and putting them back together again. I also think I got a kick from being the first and only woman in that workplace, to a certain degree.

I've read some awful tales of abuse on this thread, of women getting sent creepy messages and unsolicited judgement based on everything from their looks to their perceived lack of ability in the field. Why is it that so often a woman needs to be twice as good as a man at her job, just to be considered equal?

When I was a mechanic I got a lot of support from guys who had to adjust to a very new and alien situation that they hadn't ever been in before, but they realised I wasn't a threat and considered that it could be their niece or daughter in my place. Those men gave me the respect I deserved, which is all I ever wanted. I never wanted to be treated different based on my gender because I never saw it having any bearing on how I did my job.

I also, from day 1, took a lot of shit.

There are at least 2 sides to every story right?

Pretty much in the first week, a guy who should have known better got right up in my face and said "You're in a man's world now, love.". I swore at him, walked off and that was about all we said to one another over the next 10 years. At least we knew where we both stood.
You can't talk to a guy without wanting to make out with him of course, so before too long there was gossip that I had basically been around with every man in the place. There were a few of them, I only wish I had that much stamina.
There were a lot of sexist comments and jokes.
We often went to events like car shows and track days to provide support for the vehicles. I was frequently asked if I was "a pit bunny", valeter, sales girl, or if I was just getting a day out of the office.
One of my college lecturers didn't know how to handle having a 20-something woman on his course, so he used to call me out in front of all the 16 and 17 year old boys in the class.

I heard that plenty happened behind my back too but what you don't know can't hurt you I guess, so I didn't dwell much on that.

Nevertheless...

Fast forward quite a few years and I found myself ready to transition into a new career. I only took the decision to move into tech within the last couple of years and I've not been getting paid to do it for long, so personally I haven't been treated badly (at least not to my face). On the contrary its been a really positive experience and feels like there's never been a better time for a woman to get into tech.

So while I have seemingly swapped one male-dominated industry for another, if I do encounter some negativity based on my gender, I shall, in solidarity for my sisters just trying to do something they want to (because why shouldn't anyone?) code, nevertheless. Don't let me down, tech!

What happened at my first tech conference...

Calie Rushton — Mon, 11 Nov 2019 13:20:16 +0000

As an early-career dev there are no shortage of experiences to get excited, intimidated and a little freaked-out about. One of these is the tech conference, a mystical far-off place full of super smart people who dream in 1's and 0's, and actually know what those pretty laptop stickers are promoting.

Thankfully, there are conferences that break the mould, where the emphasis is less on stroking your chin over the latest framework and more on sharing knowledge in a safe environment where, legend has it, there is sometimes a queue for the ladies toilet.

ffconf is a really great example of how to do a conference well. I had heard about it through a couple of ladies from my meetup who had attended previously, and applied for a scholarship ticket in the hopes I could do the same. Special shout-out here to those companies that provide sponsorship, and the individuals who purchase extra tickets so that those of us of more modest means can share the experience. Without your incredible generosity, people like me are going to continue to view tech conferences as intimidating and unattainable, so I thank you from the bottom of my heart. I was lucky enough to be awarded a ticket and so last week I headed to Brighton, excited and a little nervous about what to expect.

Probably the biggest thing that struck me about ffconf was the down-to-earth nature of the whole thing. Julie and Remy who put on the conference are blessed with kids who love to help by cutting stickers and folding tshirts, and you really sense that everyone else who contributes to make the day a success are more like extended members of their family. Attendees received lots of personalised info including details of pre and post event socials, as well as a lunch organised for those who have travelled on their own. They really do seem to have thought of everything, and everything is done out of a genuine love for the community. This year was the 11th event, and the format has changed a bit over the years but their enthusiasm and dedication remains constant.

The night before the event I was a little nervous still, with no idea how I was going to get on. Next morning I walked the 10 minutes from my hotel to the venue (a beautiful old theatre turned cinema) and when I reached the front of the queue I received such a lovely welcome from the organisers that I immediately felt at ease. After collecting my pass I headed upstairs and within only a few minutes was chatting excitedly with another delegate (also a first-timer attending on her own) over coffee and pastries. Then it was time to start so we picked up some complimentary stationery (I love taking notes the old fashioned way) and headed into the auditorium.

The day was packed with talks across the spectrum of soft to hard skills, starting by considering how we can better support our peers, moving on to practical advice that can help us get better at collaborating, coding, planning, debugging and protecting ourselves online, finishing up with some inspiring examples of using code to make art and have fun. We laughed a lot during the day, but were also encouraged to consider where tech is taking us, and how that makes us feel - ffconf say their sessions are curated "FOR AN AUDIENCE THAT CARES ABOUT THE FUTURE OF THE WEB, AND, WHO WANT THEIR IDEAS CHALLENGED", and they certainly fulfilled in that regard. Some of the technical detail went right over my head but I can honestly say each and every speaker inspired me, taught me something and made me think deeply.

So that was my first conference, and I'm pleased to say not my last, as I already have another 2 booked up between now and January. Turning up to an event like this on your own can be scary even if you consider yourself fairly confident, but by heading to an event as genuine and inclusive as ffconf I had a hugely positive 'first-time'.

I think most events are all slightly different in their format so they offer different opportunities, and it's worth considering what you want from a conference. I expected I would be doing a lot more networking and perhaps at a different type of event that would be true, but the programme was packed and I felt so comfortable that I ended up having fewer, but probably more meaningful conversations. As I understand it some conferences have a lot of things happening at once, so you have to pick and choose which sessions to attend. You are bound to end up missing something but the single-threaded nature of ffconf meant I could enjoy all the talks without worrying about running from one to another and what (or who) I might miss the chance to connect with as a result.

Why you might want to use an array when writing your Christmas cards

Calie Rushton — Sun, 18 Aug 2019 17:38:56 +0000

Disclaimer: This blog contains snippets of code, but you don't have to understand them to get the gist.

When I'm learning something new I often try to think about it in terms of a real world example. I usually find myself thinking 'how would I explain this to my parents?' This involves stripping out the jargon and making it relatable to someone who doesn't understand code. If you like football and you've ever tried explaining the offside rule with salt shakers, cups and cutlery, you'll know what I mean.

When my Mum and Dad do the Christmas cards, it's usually my Dad who does the writing, and my Mum who tells him who to write them for. We could write a very simple function to show this (if you only came here for the explanation, look away now):

const writeChristmasCard = name => {
  console.log("Merry Christmas " + name + "!")
};

The function works something like this: Picture, if you can, my Mum in the living room, with the names. Dad is at the dining room table, with the cards. Mum shouts a name to him, he picks up one card and writes a nice message using that name. They have to repeat this for every single card:

writeChristmasCard("Spongebob");
// Merry Christmas Spongebob!

writeChristmasCard("Timothy");
// Merry Christmas Timothy!

writeChristmasCard("Uncle George");
// Merry Christmas Uncle George!

So all the cards are getting written, but its a long process that involves a fair bit of yelling.

If you were writing the cards, you'd probably have a list of people to send them to, right? In coding-speak, you would call this list an array. Let's get Mum to write the list as usual but rather than shout each name out in turn, walk into the dining room and give the list to my Dad so he can read it himself, and write a card for each name on that list. Quicker, and quieter! In code, the list would look something like this:

christmasList = [ "Spongebob", "Timothy", "Uncle George" ];

Each of those names is referred to as an 'element' of the array, so this list has 3 elements. There is no limit to the number of elements you can put in an array - the size (or length) of the array just depends on how many friends you have. You can give the array a title that describes it - in this case, 'christmasList' - then you can write a function which you pass that title to. The function can use this title to find out about everything contained within that array.

You can work with an array using a lot of different methods, but this one is nice because it's quite self explanatory. It abstracts away the mechanics but essentially it is 'iterating' over the array, or 'looking at each element and doing something to it':

const writeAllTheChristmasCards = christmasList => {
    christmasList.forEach(name => {
        console.log("Merry Christmas " + name + "!");
    });
 }

Returning to our example, Dad takes the list of names from Mum and iterates over it like so: he gets one Christmas card and writes the nice message using the first name on the list, then he does exactly the same for the next name, and for each subsequent name until he reaches the end of the list. By then he's got a lovely stack of nicely written cards that he finished in half the time and with much less shouting:

writeAllTheChristmasCards(christmasList);
// Merry Christmas Spongebob!
// Merry Christmas Timothy!
// Merry Christmas Uncle George!

To sum up... an array is a list of things, as opposed to one single thing. We can use arrays to perform repetitive tasks more efficiently.

If we want to actually deliver the cards we will need the addresses too, although an array isn't really suitable for that so stay tuned for the next thrilling instalment - 'Why you might want to use an object when writing your Christmas cards'

My 2nd take-home challenge, and an online coding test

Calie Rushton — Sun, 11 Aug 2019 12:00:15 +0000

Take-home challenge 2

So a few weeks back I wrote about my first take home challenge and what I got out of it. This week I was asked to look at one for another job, it was a little different in that it involved using a framework (rather than vanilla JS), and also tested some more skills like authorisation and connecting to API endpoints on a database.

The company in question is changing their whole front-end from Microsoft stack to Vue. With that in mind the test came with a Vue template which you could use, or a guide to what the finished product would look like if you wanted to build it in a framework you were more familiar with (like React, for example). The idea was to show your problem-solving in JavaScript so there was a free choice. I'd had a really enthusiastic discussion with the company over the phone about Vue, so I checked out a really nice basic intro series of blogs on here by @marinamosti. It looked really cool, I was excited to check it out so I decided to use the template and learn a bit about Vue at the same time.

In hindsight that was a bit silly. Once cool thing I gathered about Vue is that it largely handles the routing for you, by looking at the pages folder and creating a route for every file inside. A bit like Next, which I also think is pretty interesting. However, if you're coming from React you will notice that some things are really different - there's no JSX for instance: the HTML, CSS and JS are split, more like the traditional style of coding.

My big takeaway from this exercise is that a code challenge is not the time to teach yourself a new framework even if you have a template to get you started. In fact trying to build on a template probably made it worse because there were some files missing that I was expecting to see, and there were others that I couldn't figure out whether I needed to use them or not. There was a folder called 'store' (with lots of code in), which I assumed was state management, like with Redux. A quick web search introduced me to 'Vuex' and then I felt a bit more overwhelmed.

Conclusion:

If you get offered the chance to write a code challenge in a language or framework you know, take it.
Vue actually does look really cool. My 'to-learn' list just got longer.
Keep perspective in mind: a senior dev would be expected to build this app in half a day.

Online coding test

The other thing I did for a different company was an online coding test, where you write out all the code to solve a couple of problems (in whatever language you choose) and then when you hit submit, the answers go straight to the company so they can have a look. The questions were like what you would find on Codewars.

Unfortunately for me, and for a lot of other people, these kinds of tests are not where I thrive. I enjoy working through puzzles on Codewars, and I can build apps in my own time, but put me in a timed situation like that and I go to pieces - sweaty palms, fuzzy head, panic! They gave 3 questions and a recommended maximum time you should spend working in total. I pretty much used all this on the first two questions and fried my brain, so sadly I didn't get to do the third question.

I also had a pretty traumatic mock technical interview a few weeks ago: my mind just went totally blank - stuff I'd learnt just to get into bootcamp and used again in the pre-work was just...gone! I beat myself up because I should have this stuff locked down, but my mum tells me the whole family is like that so I'm going to say that technically it's their fault not mine 😊 (then go practise objects some more).

Conclusion:

You cannot over-practise the basics. The more you do something, the easier it should be to recall later.
Give yourself a break: This time last year you didn't really know what an object was, then you found out some people call it a hash and some people call it a dictionary.
You are not stupid, just remember to breathe. Some people work well under stress, others don't. We are all programmed a little differently and that's just how it is.

I love reading posts from people about how they also get stressed in these situations. I realise that sounds sadistic. It's not that I enjoy seeing other people having a hard time, but rather that it reminds me that lots of us feel like this, but we shouldn't let it devalue our sense of self-worth. Give me a 😀 or a 👋 in the comments if you feel the same way, and let's ride the struggle-bus together till it gets to our stop.

Implementing client-side logout with React Router V4

Calie Rushton — Thu, 01 Aug 2019 14:04:22 +0000

If you read my last post, you'll know I'm rebuilding the front-end of an app I built at the end of bootcamp, to use Routes instead of conditional rendering with state. I just implemented a button to log the user out of the app, and it took me longer than I was expecting, so here's what happened:

The fact I'm now using Routes threw me a little - I figured on having a Logout component containing a button, which is rendered by the AlbumsPage component (the AuthenticatedRoute) once the user is logged-in. I knew this didn't need it's own Route though, why would I need the URL of 'myapp/logout' or whatever? At this point I'm only handling authentication on the client side, which is just a matter of setting and clearing the token in localStorage. I'm going to figure out the server-side stuff later.

Asking the right questions

It seemed to me like there were 2 things I had to do to make this work:

Clear the token in localStorage
Push the url for the homepage onto the history prop

I had this function in my Logout component and passed it to the button as a prop but when I clicked the button in the app, I got a TypeError: Cannot read property 'props' of undefined. How do I get those props defined? Do I have to pass them in somehow from somewhere?

As seems to be usual for me, the answer I wanted didn't present itself until I googled the right thing. I googled the error, and a couple of other things such as "react router redirect on logout", coming to the conclusion it was a scoping issue. So do I need to bind the function? Maybe I should export the Logout component using 'WithRouter'??

Obviously none of that worked so I thought, "What am I really trying to do here?". I have a button that says 'logout'. When that button is clicked, I want to redirect the user to the homepage. When I finally tried "react router 4 redirect on button click", this wonderfully simple (but effective) bit of code revealed itself on StackOverflow (where else?):

Thank you @lyubomir !! There were 2 lightbulb moments here for me:

Seeing how to use Redirect on its own rather than in the render method of a route or any of that stuff. The react training site has more on that here.
There is another way to push the new entry onto the history prop besides writing 'this.props.history.push('/')'. The history prop is another thing for me to really get my head around / write another blog about.

What @lyubomir did which I especially liked was to extract the necessary bit of code from the full example on the react training site. I'd actually looked at this already but sometimes (especially if you are already confused) it can be tricky to identify the bit of code you're really looking for, and put it in the context of your own. I really love that these people are around to get us through when we are stuck!

So here's what my lovely Logout component looks like right now:

Vitally, it all works! Also, there was a nice reminder that another thing I wanted to do in this rebuild was to practise using destructuring a bit more. Next job for me, I think, is to look at the first use of nested routes in my app.

Setting up an authenticated route in React

Calie Rushton — Sun, 28 Jul 2019 13:34:20 +0000

After I finished bootcamp, I wanted to keep learning by rebuilding my final project - a picture-sharing app for me and my friends. It's very special to me because before I really knew much about coding, I told them I was going to build it for them. Some years ago we had a brilliant holiday to Florida, we went to Disney, did all that fun stuff and came back with a tonne of photos but never got together to share all those happy memories. Here's how it works right now:

At first I had this grand plan to rewrite it in a whole different stack, teaching myself all these different technologies. I got a bit muddled trying all that at once, so for now the back end can stay as it is - it already works well and I have the endpoints in place so I'll start by concentrating on the front. I only had 2 weeks to build the app at bootcamp, so although it works, the code could be better. This is the first part of what I imagine will be an occasional series of blogs about what I learn as I work through the rebuild.

Routing

So like I said, I built a working project in 2 weeks but I wanted to write parts of it differently. The front end is scaffolded with create-react-app and all the components are conditionally rendered using ternaries, with outcomes based mostly on different bits of state. Setting and updating all those bits of state got complicated after a while, and I thought I could go back afterwards and refactor the code to use React Router - easy, right? Well you can, and I tried, but it wasn't straightforward. Routing became my first priority for the rebuild.

The app is going to have a header with buttons going to login and signup pages, so I know I want routes for those. I also need a route for the homepage. My app uses JWT for authorisation so if there is a token present in localStorage I want an albums route to display the photo albums for the logged-in user. If there is no token, this route shouldn't work so the user needs to be shown the login form.

I created a new react app and used the quick start code from the react training website to get going. It's a really nice way to get used to links and routes by just playing about. There's a bit on nested routes which will come in handy when I get to displaying the contents of a particular album.

Once the basics were laid out with some simple components just containing h1's stating their purpose, I needed to work out how to implement the albums page: the original version of my app uses a function which checks for a token in localStorage, called at the time the album page component mounts. If there is a token, it means a user is currently logged-in, so it fetches all of that user's albums from the database.

I didn't know how to represent this with routes until I found an excellent blog on this platform by Sophie, a former grad of and teacher at the Flatiron School. After following along with first part I was able to implement this solution into my App component:

Above, there are the regular routes that I have so far, with an additional authenticated (protected) route pointing to the component that displays a page with all of a user's albums.

The authenticated route looks a bit confusing but in essence is just a functional component.

It takes in props including the AlbumsPage component, and returns a Route component. The composition of the Route is determined by its render method, which checks for the presence of a token in localStorage: if there is one, it means an authenticated user is logged-in, so go ahead and call the AlbumsPage component that was passed in. If not, use the Redirect component. Redirect is a feature of react-router-dom, you can read more about it here. Essentially it enables you to dictate what route you want the user redirected to, instead of the URL that was requested. Helpfully, you can remember the location you were redirected from.

I don't need to grab all the content from the back end yet, I just want to check whether I implemented the authenticated route correctly, so I tested it in the browser by using the console to set and clear a token...

With a token, albums page displays (just a placeholder for now):

Cleared the token, app redirects to login page (not wired up yet):

It all works, thanks @sophiedebenedetto! This is really nice and neat because rather than having those different functions in different files, I have so far kept all my routing in one place where I can see it clearly. Just what I wanted.

Next I'll go put some handlers on the login form and hook it up to the back end so I can log in one of the actual users from the database...