The UpgradeJS Blog

Whether you’re joining a team to work on an existing application, or just want to get a better idea of the status of the application you’ve been working on for a while, static analysis tools can help.

These tools can provide you with a better sense of the size and scope of your application, its architecture, and provide insight into areas of importance, high complexity, low test coverage or poor testability, and more.

Of course, these tools are no substitute for human review and team discussion, but they certainly can be used to expedite that process.

In the fast-paced world of software development, keeping track of dependencies and ensuring they are compatible with the latest version of Node can be a daunting task. This is where depngn comes in - a powerful CLI tool designed to help developers determine if their dependencies support a specific version of Node.

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.

With the release of Rails 6, Webpack was introduced as the default JavaScript bundler by using the Webpacker gem. We tend to think about Webpack only as a tool to handle JavaScript files, but it can be used to handle all kinds of asset files. This article shows how to create a Rails app that uses only Webpack to handle all the assets, including images, fonts, styles and videos.

In keeping with the first part of this series, I’ll list a few interesting issues we found when making the apps work as similar as possible for Android’s webview and iOS’ webview.

Over the last few months, we developed a couple of Snap Minis. Minis are small static web apps that are run inside a webview within the Snapchat native app.

One important part of the development was to make sure our Mini works well across different devices, especially making sure things work the same in both Android’s webview (Chrome by default) and iOS’s webview (Safari).

In this post I’ll talk about a few things to keep in mind when working with the Snap Canvas SDK and in the next one I’ll talk about some common and known issues you’ll encounter when making your app cross-mobile-browser compatible.

Contributing to open source projects is a big part of our philosophy at OmbuLabs. It’s even written into our values. Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.