The product of those meetings are technological perspectives for Yumasoft and our clients in the coming months. In this article, I’d like to share some of the technologies we are going to look into in 2023.

AI

Artificial Intelligence is one of the technologies that’s been getting a lot of hype recently. Mostly thanks to OpenAI opening its GPT-3 playground and chat. This is all fun, but companies started looking into how to use this in their businesses. We are also looking on how to leverage these new findings in AI to make our customers’ businesses easier. We think that AI can make end users’ life smoother, allowing them to focus on what is the most important.

The fact is that in many applications we develop for our clients, there is a lot of data. We have quite rich experience in developing various document and quality management systems. The data in those systems can be generally classified as documents. The documents contain tons of information. This information is currently manually enriched with metadata by the end users. In AI, we see a huge potential to automate this part of people’s jobs. NLP is very promising in this manner. It is also worth looking into the technologies like Haystack and ML.NET. The goal is that the end users can focus on their most important tasks, i.e. providing business value to companies they work for. Manual work should be limited to supervision and “teaching” the AI algorithm to perform better.

At Yumasoft, one of the technologies we are looking at in 2023, is definitely Artificial Intelligence. We think it’s a way forward in most applications of software development, especially those including big data. What’s more, implementing AI is a great marketing leverage

Guide-based forms/wizards

Diving into AI, we got inspired by how algorithms can help users fill the data online. We think that instead of presenting the end user with an old-school form containing dozens of input fields, we can ask him/her a few relevant questions and prefill the form based on the answers.

Firstly, when performing an operation in the system, the user is asked several questions in a wizard/step-by-step guide form. Finally, our algorithm analyses the user’s answers and present the user with a prefilled HTML form. The user’s ultimate role is to verify the data. What’s more, if the form’s values are corrected manually by the user, the algorithm can learn from those editions to propose better values in the future.

At Yumasoft, we think it’s better to sometimes lead the users by hand, instead of presenting them with complex, old-school forms. We’ll be exploring such ideas in the coming months.

Minimal UIs

Nowadays, we are generally overstimulated. The marketing is omnipresent. Still remember these 3-weeks-long Black Friday sales? And the week-long Cyber Monday ones just after? We don’t want our applications to make people even more distracted in today’s world.

Similarly to simplifying the forms, we think creating KISS UIs is crucial. We can also call them the minimal UIs.

For instance: let’s assume we have a dashboard. The dashboard shows many things: new procedures, unread documents, some actions to take, people to call, notifications, company events… Usually, you as a user are only interested in what you actually need to do – now and today. The typical dashboard may contain too much information to easily spot the really important things requiring your immediate action. A solution to that could be presenting a simple indicator, like a colored, pulsating dot in a place that is central to the user:

The goal is to clearly see, in a single place, whether you have something to do for now or not. This is the only thing you’re really interested in.

Such an approach simplifies working with the system and saves a lot of users’ time. It is also based on showing as little information as possible to get the job done.

React

As per The State of JS 2021 survey, React is currently the most popular front-end framework on the market. We’ve already been working with it for a long time, but it seems that we will be exploring React even more. At the moment, React is our default choice for new projects.

SaaS

For some of our customers, we are still maintaining heavy desktop clients, including Windows applications. These programs require quite good hardware, as well as manual installation and maintenance. If the application we develop makes use of external desktop tools like Microsoft Office, this also adds the costs of licensing for every end user.

As a consequence, the businesses are expecting to move the software into the cloud. SaaS looks like the preferred model. Web apps only require a modern web browser and Internet access to be used. Additionally, end users don’t need to worry about licensing. Most of UI and other frameworks are licensed per application or per developer. This is a huge difference to desktop applications, where every end user must possess a proper license for the operating system and used programs.

Finally, it’s much easier to maintain SaaS-based systems. The updates are provided to everyone in a timely manner. It adds some complexity on the development and infrastructure, like keeping the backwards compatibility, but it seems to be worth the effort. Heavy clients are fading away and becoming unwanted in most use cases.

Cloud

Last but not least, at Yumasoft we are looking to more integration with cloud services like Microsoft Azure, AWS and Google Cloud. This goes together with betting on SaaS. Delegating the infrastructure to the cloud makes the maintenance much easier and smoother. Moreover, cloud computing services provide AI platforms and tools. The examples include Google’s Document AI or Azure Cognitive Search.

Of course, moving the data into the cloud comes with challenges. Data anonymization and security should be of a great concern here.

Summary

All of us – the technical teams as Yumasoft, our clients, their customers and finally – the end users – will have to go through a transformation which is happening right now. AI will bring a lot of improvements into most areas of our lives. Cloud computing will challenge all of us in terms of privacy and willingness to share our data with external companies. Will we trust them? Will we decide to go with the innovation flow, sometimes sacrificing our current beliefs?

We are so excited about the coming months. We look forward to 2023 and can’t wait to get our hands on these technologies!

The post Technologies We Are Looking At In 2023 appeared first on Yumasoft.

Disclaimer: I’m not describing the migration process step-by-step or TypeScript itself in this article. You can find many resources on that online, including official TS docs.

JavaScript to TypeScript migration strategy

If you search online, you will find many possible strategies of migrating JavaScript to TypeScript. We considered two of them:

• converting the whole JavaScript codebase to TypeScript at once
• starting to use TypeScript compiler and migrate step-by-step.

After a short discussion, we decided to go with the step-by-step migration strategy. Why? First, it’s less time-consuming. Today, we know that it would kill us if we decided to convert all our JS codebase to TS at once. It would also freeze our codebase for a while – until every .JS(X) file is renamed to .TS(X) and all compile errors are fixed.

Thanks to the fact that TypeScript is a superset of JavaScript, .JS(X) and .TS(X) files can co-exist even if you switch to use TypeScript compiler. That’s because every JavaScript is also a valid TypeScript code and TS compiler can handle it.

That’s very comfortable. Just think about that – you can switch your project to TypeScript without actually having to change any code. We decided to immediately re-write a few of our recently-added functionalities to TypeScript and convert the rest gradually.

What TypeScript gave us

Before I tell you about the struggles, I want to really encourage you to migrate JavaScript to TypeScript. After 1 year since we switched to TypeScript, I’m telling you it’s the best thing you can do to your web app ?

Let’s see what you’ll gain if you decide to migrate JavaScript to TypeScript.

Types in new code

As soon as you switch your compiler to ts-loader, you can start creating files with TypeScript extensions (.TS, .TSX). It means that all your new code can now leverage types:

Enjoy ?

Typing information for existing libraries

Have you been wondering what about the external libraries you are already using? How to get types for them? I was thinking exactly about this before migration.

It turns out that after you migrate JavaScript to TypeScript, most of the npm packages you use already have built-in typing information. You can check it on your package’s npm page:

If it doesn’t, you can try installing npm package called “@types/your_library_name”, e.g. npm i @types/backbone.

As a last resort, you can create the declaration files yourself.

JavaScript-TypeScript coexistence

A huge benefit of TypeScript is that JavaScript code can co-exist with it. If you are like we were a year ago, with a lot of legacy JavaScript code and are afraid of switching to TS – don’t be. TypeScript makes it very easy to maintain your JS codebase or even mix it altogether.

There are no issues in using JavaScript code in TypeScript and otherwise. You can even use JS components in TypeScript. We used to have a services.js file where we kept “services” exported as follows:

After migrating it to TypeScript (meaning renaming to services.ts) it turns out that these two definitions can co-exist, even in the same file:

As you can see, we added typing information to the legacy StockService as well. That’s because we have noImplicitAny enabled in our TypeScript configuration. It doesn’t allow leaving any variables which are of any type. In any case, if you don’t know what type to use for a given variable/function, you can always type it explicitly as any, while moving the new code to fully-typed equivalents. That’s the power of TypeScript ?

Compile errors

I should have started with that! It might be obvious, but not for people who only worked with JavaScript on the frontend before ? Sure, you could get suggestions and warnings with ESLint, but that’s not the same as really enforced types checking on compilation level:

Many TS compiler options

TypeScript compiler has many useful configuration options. If you want to support JavaScript alongside TypeScript, you should enable allowJs. We have already mentioned the noImplicitAny setting that forces you to always explicitly specify types in your code. There’s much more stuff helpful in various scenarios of JS-TS migration. We were having some issues with imports from modules without default exports – enabling allowSyntheticDefaultImports saved us there.

What I’d like to emphasize here is that TypeScript compiler is really helpful ? It allows you to set your “typing” level by enforcing less or more rules. Thanks to that, you can slowly move towards more strict type checking rules like noImplicitAny. You’re not forced to do that from the beginning.

Better coding experience

This is definitely the best thing about TypeScript. It just feels more right to use it than coding in plain JavaScript. I see no reason to start a new project with vanilla JS today. I’d say even more – I see no reason to not migrate your JavaScript app to TypeScript. The sooner, the better!

You can catch your errors earlier. No need to debug the code to see if the property you used actually exists on an object. Your IDE gives you code completion suggestions. It’s a pure pleasure ?

Migration challenges

Of course, we met some challenges during migration. I don’t call them issues, because they are all manageable. Many people have already done those things, so you can find solutions to almost any issue online. Let’s see what we had to overcome.

webpack configuration

If there’s something I don’t like about web development, it’s definitely webpack... This is a typical “fighting with machines” case. Poor documentation, lack of well-described solutions online and some specificity in every project.

We had problems with babel-loader which we used to transpile JavaScript files before switching to TypeScript. Initially, afraid of introducing a regression, we wanted to keep babel-loader for legacy JS files. We couldn’t make it work, so we decided to switch completely to ts-loader for all files (including JavaScript ones).

Next issue was a lack of proper source maps and problems in debug mode. The breakpoints were often not hit. After a bit of searching and trial-error sessions, we found a solution. It was necessary to modify webpack.config.js and set devtool webpack setting to eval-source-map. We also had to use source-map-loader for JavaScript files. Finally, this webpack configuration solved the debugging problems:

You need to be really patient with webpack… But if you have already worked with it, I guess you know that very well ?

Adding types to legacy JS code

Adding types information with noImplicitAny set to true is sometimes challenging. Especially if you have some bigger JS files with no typing information at all. Sometimes you need to search for function’s calls to find out of what types are its parameters. In other cases, you might need to run your app and see that at runtime ?

Fortunately, as we already said, TypeScript doesn’t force you doing that. You can play with tsconfig or use @ts-ignore as a last resort.

Handling libraries without types

Some of the libraries we used don’t provide any typing information. It makes working with them a bit difficult, especially if your TS compiler is already configured in a bit stricter mode. In such case, you might get an error similar to the following one:

Your options here are to either write the declaration files yourself, or import the library differently. You can, for instance, require it:

const FormIO = require('react-formio');

and then use this FormIO variable which is typed as any. Again – that works because of TypeScript’s flexibility, but might not be very comfortable to live with.

Migrate JavaScript to TypeScript – should I do it?

Of course! There’s only one right answer. Don’t wait too long – start being more productive with TypeScript as soon as you can ? Believe me – you will not regret it.

The post Migrating JavaScript React App to TypeScript appeared first on Yumasoft.

Context

In our case, the component we wanted to render was CKEditor5. It’s a tiny and simple WYSIWYG editor.

Its documentation gives the following example on how to render the editor using a static create function:

In our application, we have a React function component:

The goal is to render the ckeditor component within the div with id my-ckeditor.

Can I call the component’s create function in React component?

The first idea that came to my mind was to somehow call the static create function from ckeditor providing my-ckeditor as DOM element’s id. However, it turns out that we cannot do it directly in the function component before returning, because our div is not loaded into the DOM yet at this moment.

Fortunately, there’s another, easy solution ?

React on DOM element being mounted with useCallback

What we basically want to achieve is to execute the create static function provided by ckeditor when our div is mounted into the DOM.

Let’s first install the ckeditor5 classic editor npm package:

npm i @ckeditor/ckeditor5-build-classic

Then require ckeditor.js file as Ckeditor in the .tsx file with our component:

const Ckeditor = require('@ckeditor/ckeditor5-build-classic/build/ckeditor.js');

Now, instead of assigning an id to our div element, let’s use the React.useCallback hook and assign it to div‘s ref:

Our callback function will be called after our div component mounts (or unmounts). That’s why we check whether the node is defined, and then we can do something with that.

This is how it looks in debug mode:

As you can see, node is defined, and it’s a div. Exactly the DOM element in which we want to render our ckeditor component. Let’s now simply change console.log to rendering the editor as per documentation:

Thanks to that, we can see our editor rendered on the page:

Summary

We often use external components in our projects at Yumasoft. In case of above-mentioned ckeditor, we couldn’t use its React component (because of various reasons) and we had to render it statically using JS function. The solution with useCallback turned out to be very useful here. I hope you also find it helpful one day if you ever need to use Javascript component in React ?

The post How to Use JavaScript Component in React Component appeared first on Yumasoft.