The Lockdown Coder: Building on My React Foundation
After installing VS Code and Node.js and getting the bones of a React app by using Create-React-App, I was finally ready to start coding. It felt like a slog even getting to the point where I could put my learning from freeCodeCamp into practice.
Even when you are ready to begin coding there is still the question of what to code. I found it helpful to choose existing websites and give myself the challenge of recreating it to the best of my abilities. At the beginning I wasn’t making dynamic pages with real data, it was more of a UI challenge to see if I could recreate the look and feel of existing pages. I was trying to walk before I could run.
Using Create-React-App to get my React app started was very convenient and it’s meant to be a good way of building an SPA (Single Page Application). I needed to do more research around what an SPA was as I couldn’t get my head around it initially. If it is a single page what does that mean for navigating between pages? What is so special about SPAs in the first place? One of the benefits of having an SPA is that no reloading is necessary — this translates to a seamless experience for the user that is more similar to what you expect from a mobile app. Once up-and-running it is lightning fast. In terms of navigation you can create ‘pages’ that you switch between but, technically, it is still a single page and you are simply telling the app which page/component you want to be shown. Packages like react-router-dom will handle the routing for you so you can decide which page/component should be shown for specific URLs.
Help! I need somebody
I was already moving beyond the boundaries of my freeCodeCamp lessons and having to rely on Google searches to find what I needed. Most of the time, a quick search will lead you to StackOverflow which is the prime resource for getting your developer questions answered. You can be sure that most questions you have when starting out will have already been asked and answered. Medium is also a great resource for specific tutorials — I found it was useful for my Flutter queries and it proved to be equally adept dealing with my web based curiosities.
When it comes to HTML queries your search results will invariably lead you to either w3schools.com or Mozilla’s MDN Docs. I tend to go with MDN first because it’s more official but it can be overwhelmingly technical in which case I have a look at w3schools, which sometimes lacks the depth I am after.
With CSS queries, my go-to resource is css-tricks.com which I find incredibly useful. There is so much information on this website relating to CSS that I don’t think I have needed to find another source. The articles I come across almost always seem to be written by Chris Coyier and he sure knows his stuff.
At the beginning I definitely had a tendency to look for tutorials for answers. I could read official documentation but often found it made no sense to me and I needed more hand-holding. I needed to watch someone do it, explain what they were doing and then try it for myself. It was also easy to get sucked into tutorial after tutorial without applying the code for myself as it felt like progress but that kind of learning went in one ear and out of the other even if I did understand it for that fleeting time. Eventually, I spent more and more time with official developer documentation and tried to get to grips with it. Not all developer documentation is born equal and some are definitely better than others but if you can persevere it’s a good thing to learn at source. I am now less inclined to look for a tutorial for answers and instead delve into the documentation to find what I need. As a caveat I only felt comfortable doing this recently so be kind to yourself if you aren’t grasping the documentation in the early stages and know that it will come.
I’m getting results but the code sure looks messy
It always feels like there’s something new to learn and this will probably hold true for every developer 100% of the time. Stacking up more information, more languages and more concepts seems like a house of cards at times and I struggle to keep it all together and connect all the dots.
I had completed some of the UI challenges I had set for myself and was getting more familiar with HTML and CSS structures within my React app. Features like flexbox, grid, position, classes, forms and inputs were slowly coming into my repertoire. The next step was to move into APIs and progress to using dynamic data in my apps. However, before making that step I recognised I was getting results but my code was difficult to follow especially when looking back at older code.
One of the things that can help with more usable and readable code is to keep the business logic separate to the UI. Business logic accounts for the data you are using in your app and how you are handling it. If you can keep your business logic separate, perhaps in another file, then when you need to make changes to your data handling you can do it there. The UI is expecting to receive certain data to display but you can control how you handle that. For example, you are using an API to get weather data for your app and have created a nice-looking UI to display the information. However, you find another API that is even better and decide to use that one instead. Now you only need to update your business logic (without needing to touch the UI component) and the UI ultimately still receives the same information as it was expecting except it is from a different API, not that the UI cares!
Taking your existing code and updating it so it adheres to a better structure is called refactoring. You’ll hear this a lot. Refactor, refactor, refactor! There are so many different ways of achieving the same result when it comes to coding and refactoring takes what you have produced and makes it more usable and more readable. It’s good practice to get into even if it can be a lot of additional effort to re-do code that you have spent ages getting to work in the first instance. The phrase, “if it ain’t broke, don’t fix it” does not apply here. With React you are likely to refactor your code into separate components that can be re-used with ease. It’s one of the benefits of React so make the most of it.
Fetching data with Axios and Postman
With dynamic apps there will be a time when you will want to fetch data from an external source. REST APIs are a common way of getting data into your app. Also known as RESTful API it stands for Representational State Transfer and the crux of it is you can get a data dump after calling specific URL endpoints. For example, go to https://jsonplaceholder.typicode.com/todos/1 and you will see a JSON data object returned to you. This website generates fake data for testing and developing purposes but the JSON object will contain data on a made-up user. You could then take this JSON and use it in your app however you want.
There are a number of free, open source APIs out there and this Github post contains a pretty exhaustive list for you to consider. You’ll notice that some APIs require you to have some form of authentication in order to gain access. This is perfectly reasonable as the owners of the API want to manage who has access (after all, anyone can type a URL in a browser) and authentication helps ensure you have the right to fetch the data. Authentication can take many forms and you may come across API keys, Basic Auth and OAuth amongst others.
In your own app, there are different ways in which you can fetch API data and one popular way is to use Axios. If you need authentication then you need to take that into consideration and pass the config settings for your specific use case.
It can be quite a process getting to grips with API calls and authentication in code and sometimes you just want to check that the API call is working with your authentication details. Postman is a free app you can use to make API calls with authentication and pass any other data you might want (e.g. headers and body) and see what response you get back. It’s helpful to use Postman to make sure you can get the data in the first instance and see what kind of response you get back. Then, in your app, if the API call is not working you will know it’s an issue with the code.
Things were taking shape with my React development. I could implement HTML in my React components and style them with CSS. Now I was taking data from open-source APIs and manipulating it with Javascript. For example, I was starting to understand how I could create a React component as a template and use the .map function to cycle through a JSON data array to output my own array of templates and display this in my app. At this stage, it was late July and I had been learning React for two months.
Part 1: What I managed in 12 months with no coding experience
Part 2: Getting to grips with Flutter
Part 3: Beyond mobile apps and into the web
Part 4: Building on my React foundation
Part 5: Components and classes and hooks, oh my!
Part 6: Next.js vs Create-React-App. (Undercard: Persistent Data)
Part 7: Headless WordPress, WooCommerce and Stripe
