vocitates-blog

[vocitates-blog]

Images in Next.js app on Netlify

This week while working on my latest app I ran into a very specific issue and had to do some MAJOR rabbit hole research in order to solve it. Really there isn’t an actual ‘solution’ so much as there are a bunch of random hack-y workarounds that may or may not even be applicable depending on the specific situation.

I figured this week I’d talk a bit about how I got to my solution rather than the solution itself. The solution is super interesting and I’m really pleased with myself for having figured it out, but the process was...something else. 

If me describing several days of research and dead ends interests you, read on:

So here’s the problem. I’m building an app with Next.js. I’m using Contentful to create and send data for my app to consume. Much of that information is images that make up 90% of the site (essentially all the side does is display images and descriptions...at least at a very high level). 

I got to a place where I was pretty happy with how everything was looking and was ready to deploy. After dealing with all the standard random build issues I seem to always run into when deploying a site I finally (thought) I was all set up. I went to browse around on my new live site and boom...no images.

I was incredibly confused. Everything else was going smoothly. I got no errors anywhere. But there was not a single image anywhere. 

It didn’t take long for me to find out that apparently the next/image component is not compatible with the way Netlify builds your site. Actually unless you deploy to Vercel, chances are you’ll have this same issue. Crazy! Half of the internet is images, there has to be a clean solution to this somewhere right? Right? 

24 hours passed...I read so many articles and forum threads about this particular issue...I had like 83 tabs open in Chrome just for this. I was on YouTube. I read the docs like 14 times just in case I missed something.

Nothing worked.

That’s not entirely true. There were solutions. Crazy complex solutions that would require adding like 6 new dependencies to my project. Or someone deep in some forum boldly claiming they had solved it with one line of code. None of it got me anywhere. After a full day of this I decided to try my first workaround, if next/image is the problem...why not just not use it?

Well...I got my images to display. If you’re okay with waiting for about a solid minute for images to slooooooowly start appearing on your screen. At this point I was so disgusted I was ready to just let it be. I deployed it with the slow imaged and was ready to move on with life.

Except I wasn’t. I woke up in the middle of the night still pissed off that this app I spent so much time on, that was so beautiful and ran so well on my machine and was one of the nicest looking things I’ve ever made was simply not going to be able to be shared? Nope, unacceptable. 

Cut to me in front of my computer at like 3 in the morning 87 more tabs open.

Then I went back and read the docs again. And then finally after all this reading and stressing a lightbulb went off.

Again, I’m not going to go too deep into the solution I found that worked for me, but essentially it was, as all the best solutions to programming issues, simple enough to make you scream at having spent so long trying to get there. 

The broad strokes? I replaced the image loader some something that was compatible with deployment to Netlify, Cloudinary. Added bonus for Cloudinary, it has a plugin for Contentful that allows you to pull images directly into you content model with absolutely no fuss.

This was an example of how problems like these go. You don’t have to reinvent the wheel you just have to get good at reading documentation and applying a bit of critical thinking!

Anyway, here’s to being in the weeds!

[vocitates-blog]

One of my weak points in programming is data structures and algorithms. I am good at solving visual problems but as soon as we get theoretical or are dealing with math I get very confused and lost. I’ve decided to try and tackle this more agressively lately. This week I read about a sorting algorithm. Here’s what I learned:

[vocitates-blog]

Context API

In the past, when working in React, regarding state management, I had only used Redux. This week as a part of the project I’ve been working on, I had the opportunity to use Context instead. After a bit of practice and research, I find it far more intuitive and simpler to implement than using something as bulky as Redux. 

Here’s what I learned:

At a high level, React comes built in with a hook that allows us to pass state as props to any component and all of its children. This allows us to avoid prop drilling if we need state in multiple places. It also allows us to initialize some piece of state totally outside of the component and easily consume that state between sibling components as well.

My implementation of this was relatively simple. I created a separate directory under `src` called contexts and inside this directory created a file called `UserContext.js` (in this instance the state I wanted to manage was a logged in users information, but if I needed to manage some other state I could create another file in the directory too).

In this file I imported 2 things from react, `useState` and `createContext`

Creating the actual context is a simple as this:

`export const UserContext = createContext()`

That’s really it, however there is no real functionality here. The pattern I discovered that I like and decided to use was to also export from this file as default a Provider function that would return the actual provider needed for other components to consume from.

This provider function will have other functions inside it that allow components to read and update state or any number of other things I want to pass down to them. The Provider will take all of these functions/varibles/etc into its values prop and pass them down to the consuming component using the `useContext` hook.

In this case I just created a login and logout function. I also declared a piece of state for `user` and passed all those a values into the provider allowing me to access any of these things from any component i tell to consume from this file.

Easy as that! Much less overhead than Redux and perfect for a relatively small project like this. 

[vocitates-blog]

The Project I’ve been working on lately has been a really eye opening experience in a lot of ways. Working in a group I’m being exposed to all sorts of things I never have been before. When discussing what tech stack to use, I suggested using React for frontend and RoR for the backend of the application. Everyone was on board for React of course but I was the only one who had ever used RoR for anything. Everyone else in this group was mostly familiar with Node.js

This week, so as not to be left out I started from the basics teaching myself Node. Here’s what I learned so far:

Node.js is so popular because it essentially allows us to run JavaScript directly on out computers. This is cool because usually JavaScript lives in the browser exclusively. Theres a bunch of really neat computer science tricks happening under the hood but essentially, Node is a wrapper that translates Js into something that can be compiled down to C++ and ultimately understood by the machine. 

With regular javascript everything is tied to the global `window` object and basically all methods are chained off of that by default. In Node there is a similar concept of the global object that is assumed and has a variety of methods that can be chained off of it.

In my very early learning of the basics as well, I learned that one of the cool benefits if Node is being able to essentially perform CRUD actions on the file system with Js. 

I have plenty more to learn but just from the very basics I think I’m going to like Node a lot and from how popular it is I think it will be a super useful skill to have under my belt. Can’t wait to try it out on a real project soon.

[vocitates-blog]

Headless CMS

I was recently creating my portfolio site in Gatsby and while I was reading up and trying to learn a bit about the framework, I came across a term I’d never heard before. ‘Headless CMS’. After a bit of quick reading I discovered that this was something I definitely wanted to incorporate in to a future project.

What is a Headless CMS

Headless CMS or Content Management System, is essentially a tool or managing the data or content of a site or application, without the frontend business attached. For example, Wordpress is not a headless CMS since the content you create is pumped directly into a theme. A service like Contentful is a headless CMS since it allows you to create content but is completely agnostic about where that content goes.

How does it work

I’ve chosen to use Contentful as the CMS behind my latest project which is a simple app to show off my builds in The Sims 4. Rather than creating a whole backend API on my own (doable, but probably more work than really necessary) I used Contentful to model my data. Just like you would when creating a model in a regular backend, Contentful allows you to simply describe the type of data you need, it has various categories for the data attributes (text, media, boolean etc.) each attribute can be given various validations, such as required to match a regex or some other pattern, length, or even must be limited to some pre specified set of values.

The frontend of Contentful is super clean and easy to use, so if someone is only responsible for creating content for your site or application they don’t need any technical know how to do that. Just type it in or upload and publish and the content is immediately available.

Contentful provides developers with a unique ‘space id’ as well as an API key that allows them to access the data the same as you might for any third party API. Simply store these values as environment variables in the .env file in your project, access them with process.env.YOUR_VARIABLE_NAME_HERE and use the data you’ve uploaded to Contentful in your frontend application. 

[vocitates-blog]

I keep seeing BEM listed on job applications or mentioned in technical articles and I finally decided to learn what exactly they were talking about. Turns out this may be something I find really useful in future projects and I'm glad I took some time to investigate. Here's what I learned:

What is BEM

BEM is a methodology that helps developers to create reuasable components and code sharing in front-end development. It stands for Block Element Modifier. What does this actually mean? I find it to be useful to look at an actual example.

<div class="card"> <img src="image.png" alt=""> <h2>Title</h2> <div class="content"> <span>onething</span> <span>twothings</span> <span>thirdthing</span> <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Rerum eum facilis assumenda est facere officia, minima corrupti doloremque excepturi ducimus.</p> <ul> <li><a href="#"></a></li> <li><a href="#"></a></li> <li><a href="#"></a></li> <li><a href="#"></a></li> <li><a href="#"></a></li> </ul> <button>somevalue</button> </div>

Consider the markup above. This is pretty standard, but can be made a bit more effective with BEM. With this methodology, the Block is the .card div. It's a standalone entity that is meaningful on its own. Elements are part of a block that have no standalone meaning and are semantically tied to its parent block. In our example that everything inside the .card. Lastly a Modifier is a flag on a block or element that's used to modify appearance or behavior.

BEM uses __ to indicate an element, and -- to denote modifiers. In our example since the Block is .card, the elements inside that would all be prefixed with that so for example the <h2> would get the class .card__title and the .content div would get the new class name .card__content. Additionally if we want to add a modifier, say to the button to change it when its disabled we simply do this .card__button--disabled

Our example BEMified might look something like this:

<div class="card"> <img src="image.png" alt="" class="card__image"> <h2 class="card__title">Title</h2> <div class="card__content"> <span class="card__note">onething</span> <span class="card__note">twothings</span> <span class="card__note">thirdthing</span> <p class="card__description">Lorem ipsum dolor sit amet, consectetur adipisicing elit. Rerum eum facilis assumenda est facere officia, minima corrupti doloremque excepturi ducimus.</p> <ul class="card__list"> <li class="card__list-item"><a href="#"></a></li> <li class="card__list-item"><a href="#"></a></li> <li class="card__list-item"><a href="#"></a></li> <li class="card__list-item"><a href="#"></a></li> <li class="card__list-item"><a href="#"></a></li> </ul> <button class="card__button card__button--disabled"></button> </div> </div>

Okay but the CSS

The CSS for this would be pretty straightforward. Like always you simply use selectors to target the specific elements. I however love Sass and using Sass and BEM together is magical. Here's some of what the Sass might look like for this example.

.card { ... &__image { ... } &__title { ... } &__content { ... } ... &__button { ... &--disabled } }

Here the nested selectors using & prevent us from having to write the parent selector over and over, just reference the element with its flag. And for the --disabled modifier we nest that within button since its specifically for that. When Sass compiles of course these will all be separated out into separate selectors that the browser can understand but as far as making sense to a human this is a vast improvement, especially for large projects where naming can quickly get out of hand and super confusing.

Conclusion

BEM is a great way to avoid specificity issues when trying to style large projects, and when combined with Sass it's an awesome workflow that should reduce stress and confusion when writing code and we all want that!

[vocitates-blog]

Modular Styling with Sass

I love writing Sass. I got my start writing code by created extensive stylesheets in CSS for my tumblr blog. Anyone who has created themes for tumblr knows that the process of writing your styles all in one long shot in between <style></style> tags within your HTML can be nighmarish at best. Everything is in one long document and the process of creating any sort of modularity/using multiple documents is certainly not intuitive or particularly consistently effective.

This was the environment that I first started to learn code in so of course you can imagine that when I learned about modularity in code; the ability to use multiple documents to break up code into task specific chunks, I was over the moon.

I've been working to create a portfolio site over the past few weeks. It's finally live and I've been sharing it with everyone I know. I could have written it using basic HTML/CSS and a tiny bit of JavaScript. Had several hard coded static HTML pages and styled each one with some complex set of various stylesheets. For the amount of content that honestly wouldn't have been a totally unreasonable solution, however, I wanted the tech stack used to create this site to be rather a bit more modern. I chose GatsbyJS as the core technology. I love React, but wanted to simplify since and SPA, while always nice, is not really needed in this instance (I have no dynamic data and only a couple of pages).

What is Sass

The other primary technology I chose here is Sass. Sass is a CSS preprocessor scripting language. Essentially Sass allows you to write 'CSS' in a variety of modified ways. It takes what you wrote in Sass and translates it into regular old CSS.

A ton of Sass features have been slowly added to CSS over time, such as variables, but Sass still has a TON a functionality that it will likely be years before we see in CSS, if ever.

Why I love Sass

The main reason I started using Sass was because of what I mentioned earlier, modularity. In the past I had always written CSS as one long document frequently finding that I would get lost in a spaghetti code like mess. Hundreds and hundreds of lines, random confusing selectors. It was pretty tough. There of course are standardized ways that people have learned over time to organize things, and of course you can also create a bunch of stylesheets and link them all in your HTML if you are so inclined. I am not so inclined.

Instead, with Sass, I can link one sheet, say index.scss and simply write a few brief @use rules at the top to link whatever other documents I create.

For example, in my portfolio site I have src/styles/index.scss and at the top of that document I simply reference the stylesheets I created for page specific styles such as @use './layout', and @use './contact' (notice I didn't specify '.scss' at the end of these file names. Sass assumes that for us). I also can reference various modules that contain useful snippets of code such as variables or mixins. For example I have @use './fonts' and @use './colors'

This structure is awesome for a lot of reasons. For one each document has one job, so when I need to make changes I don't have to search all over the place, I have one place to look and it's done. For example I was so indecisive about what font to use for headings all through out my site. Rather than having to go through the entire document and change the CSS rules in a million places, I have one document that takes care of all of the font stuff.

@import url('https://fonts.googleapis.com/css2?family=Abril+Fatface&family=Roboto:wght@100;700&family=Roboto+Mono:wght@300&display=swap'); $roboto: 'Roboto', sans-serif; $monospace: 'Roboto Mono', monospace; $display: 'Abril Fatface', cursive

What's happening here is I am importing various fonts from Google Fonts, and assigning them to variables. In order to use them in any document I simply need to @use it at the top of the document, and then do something like font-family: fonts.$display to use Abril Fatface font. If I do that several places throughout several documents, but then suddenly I decided that I wanted to use Lobster instead of Abril Fatface, I only have to make that change in one place and it applies to every document where it was referenced. Very nice!

That's just the tip of the iceberg when it comes to the power of Sass.

Mixins are life changeing

During the process of creating this site I used mixins for the first time. Mixins, similarly to variables contain bits of reusable styles, however, where variable will usually only have one CSS rule referenced, mixins can have a whole host of things inside them that you can easily reference throughout you various documents.

In this project, I used mixins in a couple of very powerful ways. I had a few elements on various pages that I wanted to be animated. I wrote some simple custom animations, but I didn't want to have to clutter up any other documents with long @keyframes rules. Enter mixins. Here's what I did:

Create a _mixins.scss partial in my styles directory and reference it in index.scss

Create a new mixin in the mixins document like so

@mixin animations () { ... }

Inside the curly braces, write your animations as you usually would.

@keyframes wave { 0% { transform: rotate(0deg); } 50% { transform:rotate(20deg); } 100% { transform: rotate(0deg); } }

Pull animations mixin into the index.scss using @include. In this case @include mixins.animations;

Use the animation you pulled in to create a class selector.

.wave { animation: wave 2s ease-in-out infinite both; }

Apply this class to any element you want to animate. For example I used this animation to make a hand Emoji wave on the landing page of my site.

Using this technique you can create a whole animation library quickly and easily and be able to apply them consistently while keeping your code base clean and organized

CSS Libraries

I love to write CSS. As a result, I almost never use any of the popular CSS frameworks of libraries like Bulma, Bootstrap, or Tailwind. They are awesome tools for getting things up and running quickly and consistently, but I simply enjoy writing CSS so much that I prefer not to use them. Also they are as streamlined as possible, but nothing is as trim as a library of only the specific styles you actually use. With Sass, creating a simple CSS library is super easy, and I find it a much more satisfying result since every line of that code was purpose written for my specific project. If I want to implement a border-radius on several elements and I know it needs to be 6px or 10px, I have the flexibility to just declare that as a couple of variables (maybe $radius-6 and $radius-10) and go from there.

[vocitates-blog]

I'm finally at the finish line (for now) with my personal portfolio site. Most of the development is in a good place and it's time to actually deploy the site to live on the internet!

As exciting as all that is, I actually have never deployed a site before and the process seemed daunting. After a bit of research, I discovered a very simple and steam-lined way to get my site hosted; Netlify. I've heard of Netlify before, but never investigated any further, so I decided to take a closer look at this. Here's what I learned and the steps I took.

Step One: Build

Netlify has a few different ways that you can handle getting your site deployed with them. I decided to go with a method that links directly to the GitHub repo and re-deploys the site with updated code whenever you push it up. This seems to me like the least fussy way to handle this, and for something as relatively simple as my portfolio, this was a perfect solution.

First I signed up for a Netlify account using my GitHub credentials. Then from the overview page, I just selected the big green 'New site from Git' button and followed the prompts. Literally that easy. Link the repository and you're done.

Case Sensitivity and Netlify

I did run into an error however during the build process that I think might be useful to share. During my development process, I changed a bunch of file names to make capitalization consistent through all the files. This is fine, and as someone who gets obsessive about details, it simply had to be done. However, keep in mind that Git does not care about case, but Netlify does. I repeatedly kept getting an error that several of my files didnt exist and didn't understand why at first.

Essentially, in Git, my file was was at src/components/layout.js however in reality the location was src/components/Layout.js. For git purposes this does not matter, but for Netlify this will throw and error and prevent your build from completing.

The fix I discovered for this is pretty simple. Just renaming the file won't help because again, git doesnt care about case. Instead you can just replace the file in git with the correct one.

Example, take my layout.js from forom before. In order to correct this, from the command line, I typed git mv src/components/layout.js src/components/Layout.js. This is explicitly telling git to rename these files. Once successful it will stage the change and you simply have to commit, and push it up with the updated file names. Voila no more case sensitivity error.

Other issues

I had another smaller issue with the gatsby-plugin-manifest in gatsby-config.js. Essentially, I had deleted the default Gatsby icon from the images directory, and this is referenced in this document. During development it's not an issue but it will break during build.

My quick fix to get this moving along was to remove the entire thing seeing as the data there is really just related to the Gatsby default starter and not my custom site. I haven't run a new build with this correction yet so stay tuned, but I currently am using my own image in that file because without the manifest the development environment breaks. Will see how this works when I re-deploy, but I dont think it'll be an issue.

Custom URL

Having the site live is awesome, however, the URL that Netlify will automatically assign is very ugly and not easy to share. In this instance I need to be able to send a link to this site to potential employers, so I need something clean, professional and succinct. I chose to purchase a domain from Google. That process couldn't be simpler. Just go to Google Domains, search for a URL you like, if it's available, purchase it. Done.

The challenge was making my custom domain mcooper.dev point to the gibberish URL from Netlify.

This process was...not complicated per se, but it was certainly out of my wheelhouse. I referred to a couple of neat video tutorials on YouTube to get this done. The essence here is that you have to get some info from Netlify and pop it into Google Domains so that they can talk to each other.

All Done....For Now

Deploying a site with Netlify is super easy. I am still making some updates to the code (for example I found a few visual bugs with my responsive mobile version, and I decided I hate the color palette I chose), but I know it'll be super easy to re-deploy. I don't even have to do anything but push the code up to GotHub and Netlify automatically handles deploying changes! How neat!

[vocitates-blog]

Using static data in React

While working on a Gatsby project recently, I found myself in need of a way to import some data into another component to display it. Typically this would be done by making an async call to your database or some external API and then using your component to translate that data to display on the DOM. In 99% of situations this is what you want, so 99% of information on this topic outlines various ways to complete this task.

However, for my particular case this was not what I wanted. The data I have is a fixed, static bit of data that I would store within the application itself, not in a database, not pulled from a third party.

This use case is not common, but should anyone be curious, here is how I accomplished this.

The Problem

I am currently making a personal portfolio site to send to potential employers as I job hunt. One of the most important things in a portfolio of course is examples of your work. Currently I have about 5 projects that I would like to highlight here. The model for this data is relatively simple; each project will have a title, description, GitHub link, an optional link to the live application, an image and an array containing the technologies used to create it.

Since it’s only 5 or so objects I’d need for this, the idea of creating a whole backend to manage this little bit of essentially static data seemed like overkill. What I decided to do instead is manually write some JSON with the data I needed and store it locally in the application, in src/data/data.json.

The Setup

The issue here is exporting JSON and using it in another component. My solution here was to simply use a JavaScript file instead. So now, my data is here.

src/data/data.js

and is structured like so:

export const Data = [ { title: 'project 1', description: 'Lorem ipsum dolor sit amet.', github: 'https://github.com/account/slug', image: 'image1.png', technologies: ['ruby','html', 'css'] }, { title: 'project 2', description: 'Lorem ipsum dolor sit amet.', github: 'https://github.com/account/slug2', image: 'image2.png', technologies: ['react','redux', 'sass'] }, ... ]

The Solution

With my data now structured like this I am free to import and use it in any React component.

This is done by adding import { Data } from 'src/data/data' to the top of the component, and then calling it however your need in the component.

In my application it looks somewhat like this:

const projects = Data.map(project => { return ( // I made a separate component //to handle creating individual //cards for each project ) })

Then, in the return of your component, you simply call {projects} and it should output your data formatted and styled however you like.

Other Uses

This technique can be used for a variety of things. For example, I cam across a library of icons I'd like to use. Rather than hard coding them into the JSX each time I want to use them, I can simply store the icons in src/data/icons.js and then refer to them this way. Formatting this like a JSON object is handy because you can easily store multiple icons with useful names associated with them and simply call on them using dot notation in the JSX.

I personally am using this to add emojis easily throughout my application. I created an component that takes some props to properly format an emoji using its hexadecimal code, and I have a small library that contains the hex code associated with a simple description of that emoji for accessibility (all emoji should have a role="img" attribute as well as an aria-label for screen readers).

Conclusion

This is a relatively straightforward process, but one that I found next to no information on throughout the web. Certainly nothing particularly clear. Using static data like this is not very common, but on a smaller project like mine it makes more sense than creating a whole separate backend, or calling in whole libraries of information when you only need 2-3 bits of data.

[vocitates-blog]

Setting up Gatsby

This week I decided to dip my toe into learning Gatsby. So far it’s wonderful. If you’re someone who enjoys React, Gatsby is absolutely a tool I recommend adding to your belt

What is Gatsby?

Gatsby is an open source static website generator that is based on React. From what I understand to simplify it is really just a simple way to build sides using React without a lot of the business of setting things up. 

Many of the features you may have to add to a React project are built in when using Gatsby. For example, routing in Gatsby is mind-blowingly simple. A Gatsby project will have a directory located at /src/pages. Any React component defined in src/pages/*.js will become a page. Meaning src/pages/about.js will automatically be available at localhost:8000/about. 

Gatsby uses GraphQL to get data meaning it can get data from just about anywhere, from a database, common CMS’s like WordPress, or even a simple CSV. 

How to get started Using Gatsby

The Gatsby docs are very clear and helpful for getting up and running. They even have a whole section devoted to helping you set up a development environment if you need to.

Personally I have completed the first section of the docs to learn some of the basics. Generally its a simple as running gatsby new [project name] from the command line to create a new repo with the default Gatsby setup files. 

From there most of the set up for a basic project is done. You’ll need to import react to each component like always and then create your components as always. 

Next Steps

I have a bit more learning to do but I’m excited do dive deeper. I want to understand if some of the modern react hooks would be available here, and if they’d even be useful for the type of projects Gatsby is suited for. Similarly for things like state management. I’m also curious about the various plugins available; is that library particularly robust?

I plan to use Gatsby to build my personal portfolio site. I’ve been digging around for a tool that will help me quickly build a beautiful frontend without a whole bunch of extra that. I won’t need since primarily the site will be presentational and have no real need of a full backend. I also wanted to write in React rather than using basic HTML/CSS/Javascript. Gatsby seems like the perfect solution so far.

[vocitates-blog]

.concat() vs .push()

I’ve been backtracking lately to look at some relatively basic things that I feel like I never really mastered or fully understood. One of those things was really understanding when to use .push() vs when to use .concat()

There are many JavaScript array methods (methods in most languages for that matter) that on the surface seem to do the same thing. In fact, in my reading to ensure my understanding here, I came across several similar situations.

The conclusion? The difference is almost always what is actually returned by the method. For example, with .push() vs .concat, push is mutating the original array and returning the element added to the array, while .concat() is going to return a new array and leave the original unchanged.

For example:

const arr = [1,2,3,4,5] const pushArr = arr.push(6) console.log(pushArr) // 6 console.log(arr) // [1,2,3,4,5,6]

vs. using concat:

const arr = [1,2,3,4,5] const concatArr = arr.concat(6) console.log(concatArr) // [1,2,3,4,5,6] console.log(arr)// [1,2,3,4,5]

It's important to remember what is actually being returned by any method you use. It's easy to overlook, but I know for me it's one of the first things I think about when i am getting unexpected resilts from some code.

[vocitates-blog]

Frameworks vs Libraries

I’ve recently decided to take a stab at learning Angular. Since I’ve got some experience in React, Angular seems like a reasonable next step. 

While some base concepts of both are somewhat similar there are some rather important differences that I’ve learned about in my study.

One major thing that I think people miss when comparing here is that React is a JavaScript library while Angular is a TypeScript based framework. While the difference on the surface may seem inconsequential, this does create some rather large variances in how you would use these technologies.

There’s plenty of writing on the specifics of the differences because this seems to be a common misunderstanding, but from what I’ve learned, the simplest way to understand this is that a Framework is a lot more bossy and opinionated about the structure of your code and how things are implemented. This can be great if you need to get things up and running and you want everything you’ll need out of the box (for example Angular has routing built in). 

A library on the other hand going to have less stuff built in, but that allows a programmer to make more choices about what specific packages they want to use (React has React Router but you may chose from several alternatives such as wouter or chose to not have routing at all in your application)

What really helps make this clear if the fact that Angular itself has libraries that can be used with it.

Ultimately what does this mean? Personally I find that React is far easier to use. It requires less to get started and is easier to understand overall. Angular has a steeper learning curve because it involves so much more. That said, this comparison, like most, will depend largely on what type of project is in question. It’s up to the developer to determine what technologies best suit the project rather than trying to force a preferred technology onto a project whether or not it’s suited for that