All you need, in order to use command line arguments in Node, is process.argv. That is an array, and it’s really important to remember that the first 2 elements will have nothing to do with your elements! They actually can differ/depend on your machine, and where the file is located on your hard drive. They can be useful in certain contexts, but when we talk about CLI arguments, we are talking about every element that comes after those 2. Often, you can call process.argv.shift() twice, to get rid of those, and you’re left with just an array of elements in process.argv. Then you can do as you please with those arguments within the program!

This sort of thing is very helpful because it allows you to dynamically give values to the program without having to save them into any files anywhere. You simply state the values when you execute the program. If you have a long list of arguments you want to supply, it of course makes sense to include those in a file or database, which is then supplied as an argument, or hard-coded for the program to reference specifically – but that’s a discussion for another day! I’m still in early stages of learning node, and I am ultimately focused on using it in the context of web server functionality. This is just a neat thing I learned, that may come in handy sometime!

The post Node Arguments appeared first on Morgan VanYperen.

They explain the change very well here. Basically, instead of putting everything into brackets as an array with commas between elements, you can now just wrap it all in what appears to be an html tag, indicating it’s a fragment. Basically, syntax is almost exactly like it was before fragments existed, but it’s not an extra div, or whatever you chose to use in the past. They have a few ways to indicate it’s a fragment, but my favorite is simply <> putting things within blank tags, like this </>.

This is really interesting to me, because while I haven’t looked into how exactly they made this work, I’m pretty sure it works about the same way as when they supported arrays – they just abstracted away a lot of the code you need to write to indicate how the fragment should be put together. In any case, I like it a lot. While it’s not anything groundbreaking, it just feels right. It’s the way things should work. So to you React devs at Facebook who definitely read my blog (lol), I am proud of you. Thanks for all you do!

The post React Just Got Better (Again) appeared first on Morgan VanYperen.

One thing that bugged me a bit when learning React, was that when you’re writing JSX, you can’t simply return a set of elements. For example, when writing html, the following sort of structure might be typical to see within the body of a document:

<h1>Title</h1>
<h4>Subtitle</h4>
<p>Some text</p>
<p>More text</p>
<img src="image.jpeg" alt="image description" />
<p>Even more text</p>

So when you’re writing a component, and want it to spit that out, it seems intuitive to just create those tags, and write it as shown above. But you weren’t allowed to do that! You had to wrap it all into a div, or span, or some kind of package. That’s very trivial to do, but at the same time, it’s annoying! I don’t necessarily want to enclose a bunch of stuff into otherwise unnecessary tags. It makes things more messy than they should be in the end, and there’s often no good reason for elements to be wrapped like that.

Thankfully, we can now return fragments! Simply wrap the JSX in brackets, and return an array of elements. So instead of throwing it all into a div, which seems more like a workaround to force it to all be technically one element, you simply add some brackets, and place commas between the arrays, indicating that you want to return each of those elements – the actual stuff you want.

The tricky thing right now is, you get a console warning, unless you assign each element a key. This has to do with how React handles arrays, and what it needs in order to identify changes or removals. For fragments in particular, it actually shouldn’t matter, but the warning will still appear unless keys are added. This isn’t so convenient, but I still like where it’s going – and the react developers said they’ll add a special fragment syntax to JSX so it doesn’t require keys. I’m looking forward to that!

The post My Favorite React 16 Change appeared first on Morgan VanYperen.

In addition to trying to generally improve the notes around my code, I also of course have to learn to code better. The project I found, that I’m working on contributing to, involves combining React and WordPress together in a pretty unique way. I have an understanding of React, and of WordPress, but I’ve never used WordPress exclusively as an API before, and I’ve never used Next.js either. Lucky for me, there is a lot of beginner documentation out there for both – and this project is still in its infancy – so there are plenty of basic things to add!

To begin my process, I simply cloned the github repository, and followed the readme’s instructions for installing dependencies and launching the site in a local environment. Then I opened up the project in my text editor of choice (vscode right now) and looked it over. While I haven’t used Next.js before, everything for the front-end looked pretty familiar and intuitive based on my experience with React. I familiarized myself with the file structure, and where code and/or libraries were being imported and exported. The WordPress folder was of course, very familiar to me from my time working at Bluehost. Nothing new there.

As I saw how routing was working on the front-end, I knew I’d need to study more about Next.js if I want to help add components to display pages and posts. That seemed the most obvious thing to add at this point, but it was still unclear to me how to build that out. Here is where I went to learn to how Next.js works, and how I can add to the project. It’s really nice because it even has a section for creating dynamic pages – exactly what I want to be able to do when creating a custom react front-end for WordPress. Now that I have a pretty good understanding of how that works, I should be able to get started following that pattern, and document my work properly with git commit messages. The next tricky part is figuring out what urls to use to fetch the data from WordPress, and make sure the links all work properly. More on this to come.

The post Contributing to Open Source appeared first on Morgan VanYperen.