The UpgradeJS Blog

When we started offering productized Node.js upgrade services, we wanted to bring our technical debt expertise into the JavaScript ecosystem, with the goal of helping as many people and companies as possible.

Unfortunately, in the past we’ve had to turn down companies who wanted to work with us but couldn’t secure the minimum monthly budget to work with our experts.

I’m pleased to announce that we’re now offering new opportunities for startups and small businesses to work alongside our team.

In this article, I will share a few new options to collaborate with our team of experts who specialize in technical debt remediation.

When we join a project and it’s full of jQuery code everywhere that mostly handles simple functions like: selecting elements, add style to an element, handle AJAX request, and it was added a long time ago, maybe it’s time to start migrating small things to simple JavaScript code.

React 18 has been out for about 8 months now and it contains a ton of goodies for both end-users and library authors. However, there is one new change that seems to keep coming up in GitHub issues and forum posts – useEffect now fires twice under Strict Mode in development. In this post, I’ll briefly go over exactly what Strict Mode in React is and then offer some advice on dealing with the change – as well as a few useEffect best practices.

The JavaScript ecosystem is moving incredibly fast these days. It seems like there’s a new framework or library every other day. For developers trying to jump in, it can be daunting to figure out what tools to choose for your project. It can also be difficult to tell whether or not the newest thing is ready for production.

So, to help you navigate the maze of choices, I’ve compiled a list of the basic things you need to get started with a modern JavaScript project. This collection isn’t exhaustive, but represents tech that is both current and stable (not ancient, but not so new that it’ll break prod). Also, when applicable, I’ll include upcoming tech that is promising, but maybe not quite ready for primetime.

No, not that Meta

What most developers call JavaScript frameworks (React, Vue, Svelte, etc) can more accurately be thought of as UI Libraries. While they can make writing the front end of websites and apps simpler, they have no opinions at all regarding what goes on further back in the stack. They don’t even have prescribed methods of organizing the folders and files in your projects.

Full-fledged frameworks (think Rails or Django), on the other hand, will usually be very opinionated and expect the code to be organized in a certain way, with the hope that this will lead to shorter development time by getting rid of analysis paralysis and bikeshedding.

Thankfully, there are libraries available to fill that role in the JavaScript ecosystem. Since most UI libraries are called “frameworks”, these more full-featured libraries have taken to calling themselves “meta-frameworks”.

In a nutshell, they let JavaScript developers focus on the “what” and take care of most of the “how” for you.

We, full stack Rails engineers, have come a long way. We started off as full stack engineers with our backend and frontend all in one framework. We had the asset pipeline (with sprockets) to help us maintain this ecosystem. When the time came we introduced webpacker to fill in where sprockets fell short.

In this post we will take a look at how we can take the next step on our journey by migrating from webpacker to esbuild.

When we run tests, we don’t want to hit external services in most cases, so our tests don’t depend on external services and are more stable. We can use gems like VCR or WebMock to stub the requests that are done by the Rails application, but when the request is initiated by the JavaScript code… that’s a different story.

“You can have a little imperative React, as a treat.”

When building modern applications with React, Function Components and Hooks are the de facto way to do it. Hooks make your code more declarative and easier to reason about (usually).

However, with all great hammers, you run the risk of everything looking like a nail. Occasionally, some more object-oriented solutions might be the right tool for the job. For example, what if you had a child component that contained a function that needed to be called from the parent? You might want an instance method, but we don’t use Classes anymore!

Fear not – you don’t have to abandon Hooks to be able to call methods on child components. In this post, I’ll show you how – using forwardRef and useImperativeHandle.

To the seasoned developer this may seem like a silly question, but to developers who are self-taught, bootcamp trained, or even just have never come across a project in TypeScript - understanding exactly what it is and how to use it can be a bit of a mystery.

In this article we will try to explain the basic concepts behind TypeScript, and the reasons for using it.

In modern apps, it’s common to enhance the user experience with JavaScript. Whether it’s just some JavaScript sprinkles here and there or a full JS-based frontend, this is as important as your Ruby code when it comes to the app’s correct functionality. In this article we’ll show how to measure the test code coverage for the JavaScript code when running system/integration tests along with the Ruby code coverage.