I have now been a real, live full stack developer for over two months! I was lucky enough to find a position that used, essentially, the same stack taught at Grace Hopper. We use a MySQL database, and Express server on Node, and React on the front end. This has made my transition into the job pretty seamless, I was able to quickly understand the existing codebase and start working.
There are, however, a number of technologies that we use that I had either never heard of before, or never used before, that I have learned on the job
1. Flow:
Flow is a static type checker for JavaScript. What does this mean? Well, JavaScript is a dynamically typed programming language – in plain English, it doesn’t care how often you change the types of things. You can define a variable as a string and then reassign it as a number. A function can return a number sometimes, an object other times, and undefined the rest of the time. JavaScript doesn’t care.
Especially when you are just starting out, it’s great not to worry about type. However, Having strict typing (meaning, a variable or argument will always expect to be the same type, a function will always expect to return the same type) is a good way to catch errors before they happen. Flow essentially allows you to use JavaScript as a strictly typed language.
It works well with React, because you can use flow to specify what types of properties your component should receive. Then, if you try to render a component without those properies, Flow will error. This can be, in many cases, clearer and more efficient than writing tests. Once you beat the learning curve, flow is a great way to catch errors before they emerge.
2. Jest
Speaking of efficient react testing, we use Jest on the job. What sets Jest apart from other front-end testing frameworks is the ability to take “snapshots.” A Jest snapshot creates a separate file that contains the return value of a function at the time the snapshot was created. You can use this with a React component, capturing a stringified version of the HTML that the component renders. Then, in the future, if you accidentally change something in the snapshot, the test will fail. Of course, if you intentionally change something, it is easy to update the snapshot. Because much of the labor of writing React tests is just making sure everything renders correctly, this can save a lot of time – which, in turn, makes developers more likely to write tests.
3. Yarn
We use yarn instead of npm for dependency management. I’ll admit, I haven’t taken much time to learn about yarn, mostly because the switch to yarn has had almost no effect on my workflow. The commands for yarn are almost the same as for npm, i.e. you can just run `yarn install` instead of `npm install`. Your package.json looks the same. The only major difference, as I understand it, is that yarn is faster (or something)… seems cool.
4. Async functions
I can’t lie, I freaked out a little bit when I realized that the codebase at my job almost never used promises to handle asynchronous operations. Instead they use async functions, a feature of ES2017, the newest version of javascript.
Here’s what happens. If a function needs to do something asynchronous, you define it as an async function. Then, inside the function, you get a nifty keyword “await”, which basically says “wait for this async thing to happen and then give me the result as an actual useable value.” No more chaining thens, forgetting to return a promise, or fishing around for the actual value you want. I can’t say that I am yet an expert in async function syntax, but I tentatively have the feeling that this is the best solution that exists for async in JavaScript.
Galen E. Corey 