DEV Community: Aaron Billings

AngularJS to React Migration Part 1: Webpack Installation

Aaron Billings — Sun, 19 Jul 2020 16:57:33 +0000

As I'm sure your aware AngularJS is going the way of the Dinosaurs next June being fully taken off of life support. As that is the case many companies are forced to move to new technologies such as React, modern Angular, Vue, or even Svelte.

I recently joined a company that was going through such a transition. The purpose of this article is to explain the process we took moving from AngularJS to React.

The Setup

We decided to take the React transition in a couple of steps. Since AngularJS is a framework and React is a library they can coexist in the same project. However that should not be the end goal. The end goal should be to have a fully functioning React app with no trace of AngularJS left. This is easier said than done.

The are 2 ways you can go about this.

Start from scratch.

This is probably the easiest way to move from AngularJS to React. You create a new React project by CRA (create React app). Then you can either keep it in tact or eject if you want to customize the webpack options. Then you go about building your application in React. And you probably won't even need to read the rest of this article.

Integrate React into your current AngularJS project

This is the hardest method. There are many moving parts and this will take the longest depending on the state of your AngularJS application and how modular it currently is. You'll need to add some things before hand if you want to go down this road. But be warned, this path is not for the faint of heart as it will challenge not only your resolve but also your product timelines as unforeseen issues will come up. You'll probably ask yourself at some point during the process what you did to deserve such a fate, but don't worry it will all pay off.

We decided to go with option 2. Why? you may ask. Well, our application is pretty large and has millions of internal and external customers many of whom are still using IE11 plus we have applications in Flex flash (yea, that still is being used) that also needed to be converted over as well before its EOL In December.

In order to make this move we needed to make a list of what we needed.

Webpack
A package to bridge the gap between AngularJS and React
A method of converting AngularJS to React

Obviously, there are many moving parts here and this article can only cover so much. So this will be a series that will cover the steps we took to slowly convert to React.

Welcome to article 1.

Introducing Webpack

This is probably the most important step, without setting up webpack moving to React is much harder. This is because webpack helps to move the application from total DI (Dependency Injection) to imports which will allow you to bundle your application, use code splitting, HMR (Hot Module Replacement), and live reload during development.

This article will assume you already know some things about webpack. If your starting from no knowledge of webpack, I'd recommend reading the documentation and even taking a course on it. Knowledge of webpack will help you long after the project is done.

Installation

However, before you install webpack you'll first need to examine your application and think through a couple of things especially if the AngularJS application you're working with is pretty old. Some questions to ponder could be: What will be the entry point? What loaders will you need? How much of your application is dependent on DI? How should you handle vendor files if you have them? What about templates? Are there nested templates using ng-include? I could go on and on, you get the point. Think through the implementation now and you'll save yourself a lot of trouble later on.

I decided to go with the css, babel, less, html, url and file loaders. For plugins we went with the webpack progress and the HTML webpack plugin. There are more plugins and loaders you can use for your specific needs. I encourage you to research them.

I also set up Dev, QA and Prod webpack files. Then installed webpack-merge to combine the correct env file when needed. This allows you to have different env options contained in different files without polluting your main webpack.config file making it more readable.

When webpack merge runs it examines your webpack config file then based on the env copies the env specific options you set up and merges them with the config file and executes it. I like this set up much more than previous ones.

You can also use presets which allow you to create new options and run them without affecting your config file or env files.

Finally, I added scripts to the package.json file to ensure an easy way to executing the envs for webpack builds.

If you'd like to know more about this leave a comment letting me know and I'll write an article on it in the future.

Application Setup

Once you have your webpack configurations set up you'll need to set up your entry point. I imported all of the vendor files into my entry point. Once that was done I went through and added an index.js file to each component folder and imported everything from that folder there.

I repeated this process for all of the components. This is necessary because even though AngularJS knows what should be included via DI, webpack has no idea what is needed in the bundle unless it's explicitly stated through an import statement, so we have to use this method to ensure all of our files are included into the bundle.

AngularJS Templates

Next on the list was how to ensure all of the AngularJS templates were included in the bundle. The best way I found to include them in the bundle was to change the templateUrl to template and the path to a require with the path. This would ensure the templates would be in the bundle.

Here is a before and after.

Before:

templateUrl: 'nameOfYourTemplate.html'

After:

template: require('./path/nameOfYourTemplate.html')

AngularJS can usually find your templates as long as they are uniquely named but this won't work for webpackAfter:
In order to include them in the webpack bundle we need to require the absolute path to the templates

The other tricky thing was the templates that weren't directly included in the component but nested in another template by using ng-include. Webpack has no idea what ng-include is or does so it just ignores it. You could get a package to handle this as well.

However, the best way I found around this was creating a directive (or component) for the template then using the directive syntax in the other template to include the nested one. The reason I chose this way is because once you start to rewrite all your angularJS code you will automatically know which templates are nested inside others which will make it easier on your later. It sounds more complicated than it is, below is an example.

ng-include directive:

<div ng-include= " 'templateId.html' "></div>

The ng-include is itself a directive however, webpack can't understand that the template should be included

This is the directive I created:

angular
.module('WhatEverYouWant', [])
.directive('newDirective', function() {
return {template: require('./path/nameOfYourTemplate.html')}
})

After you create this you just need to add it to your main DI list by the name you called your module in quotationsThis is the new directive included in the template below. You'll notice that the directive it self has hyphens when placed in a template but does not have hyphens when you created it.

This is because if you were to put hyphens in your directive when you created it, AngularJS would strip them out anyway. So it's best practice to camel case when you're creating the directive and hyphenate when using it.

To use your new directive in another template just add it with hyphens inside of a div tag where ever you want shown here:

<div>
<h1>My new directive</h1>
<div new-directive ></div>
</div>

Floating Variables and CSS

Next, I had to tackle what I like to call "floating variables". You may ask, "what do you mean by floating variables?" Well, in AngularJS land you can create variables and just use them anywhere in your application (unless you're using them in a template) without importing them. This is because AngularJS makes these variables global.

Now, that might fly for AngularJS but webpack and React is going to call you on that real quick. So I had run through the main file where functions and variables were declared for the entire application and export them. Then I imported them into the files that depended them so they would be included in the bundle. This by far took the longest to do, since this was an enterprise application there are a ton of variables and functions used in all parts of the application.

Finally, you'll want to import your css or preprocessed style file(s) into your entry to be included in the bundle and processed by one more more of your loaders. I would recommend to make this easier, import all of your css files into one file and import that one file into your entry. This will ensure all your styles are included in the bundle.

After completing these steps I finally moved to running webpack. (Yea, I haven't even started up webpack at this point.)

Starting The Webpack Build

By now I'm sure you starting to see this process is not an easy one. We've done a lot of work and we haven't even ran webpack yet. This was intentional, the thought process and setup really should be the hardest part of this because if you do the work in the beginning you have to do less work later on and less bugs to squash when you add React.

If you have a backend that is on another server and you want to use webpack-dev-server, you will probably need to setup a proxy for it. Here is the documentation for that, it's not too hard to set up.

After you start the webpack build process your expectation should be that your application builds without errors. If you do see build errors, they may happen because some dependency was missed or a file wasn't imported correctly.

Once the build errors are resolved and it builds successfully, your expectation should be that your application loads in the browser. You will most likely see some errors pop up. That's okay and it is expected.

Test your application meticulously to ensure all of those errors are resolved. This includes undefined variables, styles not being applied, scoping issues, templates that you should see but don't, etc. This will take you a while depending on the size and flow of your application.

Part One Conclusion

Webpack is the first and most important part of the migration from AngularJS to React. Hopefully, part one of the series helped you get your migration off to a great start. I'm currently working on writing part two and should have that out at some point in the future.

If you enjoyed this article, feel free to follow me and check out my other articles I've written here.

Are You an Imposter?

Aaron Billings — Sun, 26 Jan 2020 07:09:52 +0000

It’s early Monday morning, I sit down at my desk. It’s my second week at my first development job. It’s eerily quiet as I’m the only one in my section. I turn on my computer and take a deep breath. Just then a wave of anxiousness runs over me as I think… What will happen if people here find out I can’t code? What if I really can’t code? What if it takes me a long time to get up to speed? Can I really do this? Am I really a developer? Do I really belong here? Have I worked hard enough to get here? What if make a mistake and they fire me?

No doubt if you’re a developer, you’ve dealt with imposter syndrome. There are a ton of articles out there on what it is and how to deal with it. However, the purpose of this article is to share some of the practical things I’ve done to improve my battle with Imposter Syndrome. Hopefully this article will help you if you’re struggling with the same feelings. The most important thing to remember is you are not the only one that has experienced this.

We will discuss 4 methods that have helped me. These are certainly not all the ways one can combat imposter syndrome but they are a start to help you overcome some of those feelings.

Identify the thoughts
Confide in others
Plan things out
Putting it all together

Identify the thoughts

No matter when you have experienced imposter syndrome, the one thing that is common is that it hits you like a ton of bricks. You feel fine, you’re doing well, then all of sudden there’s a problem you can’t quite understand. Or there is an issue you can’t quite solve on your own. Then the negative questions start to circulate and the more you struggle, the more negative the questions in your mind become. If this is left unchecked it can severely damage your confidence. So what do you do?

What I do is start with identifying what exactly is causing the thoughts. What about the issue or problem I’m facing is making me feel this way. I’ll take a deep breath and ask my self some questions. Am I feeling this way because this is a challenge I’ve never faced before? Is it because I feel I’m going to fail? Do I think this is too hard for me to solve? Is this problem actually too difficult to solve?

Asking questions helps me get to the root cause more quickly. For example, let’s say I feeling inadequate because the issue I’m dealing with I’ve never dealt with before, so I feel I’m going to fail. I start to question that thought with more facts. Hasn’t every challenge up until this point been something I haven’t faced before? If I was able to overcome those, can’t I do the same here? There’s nothing different about this situation that I haven’t face before except the kind of problem right?
Once you start to break down the wall of negative questions with the hammer of facts, you begin to feel better and start to think of the issue you’re facing as not an end of something, but a beginning of something else.

Plan things out

A good way to combat imposter syndrome is to start thinking and working like a more experienced developer. The best part is, you don’t need to have a ton of experience to do it. I’ve heard from many Senior developers that the difference between an experienced developer and one that is new is planning. A more experienced developer will take time to plan things out before starting on a problem. They begin to think about all the issues that could go wrong, will go wrong, and the bugs they may experience along the way.

The less experienced developer will see the problem and start to tackle it and solve the issues as they come upon them, this usually lead to the issue taking much longer to solve and perhaps pain for the developer.

By creating a plan before you start coding you can avoid most the issues that come up. The more you plan for those issues and think about ways to combat bugs that may come up the better you’ll feel if you do encounter hard to solve issues because you’ve solved so many others before it.

This all sounds great, but how should one go about doing this? Well, what you could do is speak to your more experience co-workers. Before starting on an assignment, pair with a developer that has done it before so you can learn from their experience without any of the pain. Create plan with their help to find all of the potholes you may encounter. This not only helps you grow your skills as a developer and grow your confidence, it also helps you confide more easily in others which something else that can you help you combat imposter syndrome.

Confide In Others

Here’s the part that can scare you. You need to talk with others about your thoughts and feelings, especially other developers on your team. This helps for a couple of reasons.

First, it takes the pressure off from having to keep these thoughts to yourself the entire time. Feeling like you could lose your job at any second if you don’t figure something out by yourself can be extremely taxing.

Second, you’ll realize you’re not alone. When you speak with other developers they will tell you that they struggled with the same feelings too and a lot still do. That’s because no matter how long you’ve been a developer you will NEVER know everything there is to know about your field. Technology moves too fast, there constantly becomes new ways to do things and new libraries and frameworks to do them in.

Third, it helps you collaborate with other developers much easier. Why can I say that? Well the moment I became vulnerable with other developers, two amazing things happened. I was able to see myself through the eyes of a more experienced developer and I was able to build trust. This alleviated the fear I had of asking other developers questions and helped me be much more open with what I needed help on. As I started to complete project after project with the help of my fellow developers my confidence grew.

Putting It All Together

Imposter syndrome can hamper you, but it doesn’t have too. If you can recognize the feelings, plan things out, and confide in others you can actually use imposter syndrome to your advantage to spur you on to keep pushing yourself forward.

You maybe new developer right out of a bootcamp looking for your first job and you’re wondering whether or not you’re good enough to get a job. Or you might have just gotten your first dev job and wondering if you’re good enough to do the job well. In any case, I’ll tell you a secret. You got this! You can do it!. Things will get better, you will find a job. You will do great, just continue pushing forward and don’t give up!

If you like this article, why not check out some of my other articles.