As you can see, there are some [cached] mentions there in a few places and no [code generated] statements at all. The effect is that your bundles are not rebuilt at all. In order to have them refreshed, you need to restart the building process, which takes time and makes your development flow painful. If you want to know how to solve that problem, read on ?

webpack watch cached files

We have struggled with this issue for quite some time. It starts with launching webpack with --watch option. Such build script can be defined in your package.json in the following or similar way:

The effect you would expect is for webpack to rebuild your bundles as soon as you make any change in the source code.

When the webpack watch cached issue occurs, the first change you make in a file is properly reloaded by webpack and looks similarly to that:

However, as soon as you change the file for the second time, the output looks less promising:

As soon as you see some of these [cached] things, it probably means that webpack cached something and did not generate new bundles. Especially if there are no [built] and [code generated] statements in the output. You notice that your files are not refreshed, so your last change is not reflected in JS bundles ?

Hotfix: disable webpack cache

The first hotfix solution – especially if you can’t easily find the cause – is to disable webpack cache completely. In order to do that, you should set cache to false in your webpack configuration file:

This will work, and webpack should now rebuild your bundles on every source change. However, it comes with a significant performance cost. Disabling the cache will make webpack actually rebuilding all your bundles on each change. This solution is actually a shortcut for restarting the build from scratch. Not what we really want ? Let’s see how to find the cause and solve webpack watch cached issue properly.

Wrong casing – the real cause of webpack watch cached issue

In our case, the problem turned out to basically be wrong casing when importing stuff.

The general advice is to find how given file you are modifying is entered into your webpack’s build flow. It can be imported or required directly. Maybe it’s used via webpack alias. I know these are quite general statements, so I’ll show you two examples.

Wrong casing in import

First, we had a problem of webpack watch not refreshing bundles after making changes in a single file. This file is named questionnaireCorrectTemplate.tsx. It exports a single React component called QuestionnaireCorrectTemplate.

In order to use this component, we imported it in another file in the following way:

Have you already noticed the problem? Note that the import contains the module name with capital letter: “./QuestionnaireCorrectTemplate”. As soon as we changed it to a small letter, so exactly as the questionnaireCorrectTemplate.tsx file’s name:

Everything started to magically work ? Since this change, webpack watch is properly rebuilding our bundles after changes in the affected file ?

Wrong casing in webpack alias

We had another issue with webpack not refreshing the bundles when we made changes in a Site.css file. This is a file in which we store custom CSS for our React app. The issue was very similar to the previous one. After starting webpack watch, the first modification of Site.css file triggered a proper rebuild of bundles:

However, all subsequent modifications to the Site.css file causes the webpack watch cached issue:

The reason was wrong casing again. However, this time we found out that the Site.css file was included as an alias in webpack configuration file:

I guess you can already see what is the problem ? The file was included as site.css, instead of Site.css. As soon as we changed this part of the webpack.config.js file to the one with proper casing:

Everything started to work correctly. Since this change, webpack watch correctly refreshes the bundles after each modification of Site.css file ?

Webpack watch cached – summary

I hope this article helps you solve your webpack watch refreshing issue ? Webpack is still kind of magical tool for me and it surprises me very often. Such issues can be really painful – that’s why I wanted to share our solution to this problem with you.

The general advice is to find how the problematic file is imported/required/added to webpack build flow. It’s very probably that you have the wrong casing somewhere. I hope it saves you some pain one day!

The post Webpack Watch Cached And Not Refreshing Bundles appeared first on Yumasoft.

Even tough, you really knew that the name property exists on the person object? How did you solve this problem? Did you cast the variable to the expected type?

If the answer to at least one of those questions is yes, you might read on. There are better ways of determining the type of local variable in TypeScript. What’s more, TS compiler does a lot of stuff for us by leveraging types narrowing. In this article, we are going to see how it works and how it can be useful ?

TypeScript types narrowing – what is that?

One of the goals of TypeScript is to make writing JavaScript code better and more secure by adding the typing system. However, we don’t want the typing system to be problematic and making us to use the dirty haxes like all the time casting our variables explicitly, do we? ?

First, we need to understand that TypeScript does a lot of stuff in order to ensure we work with the most specific type as possible. Basically, if the exact type of local variable can be determined, TS compiler tries to do that.

Imagine such a function:

In vanilla JS, such code would of course compile. But in our case, TypeScript sees a problem:

The compiler is right here. Our parameter is either string or number, so the length property may not be available if someone passes a number.

You might have already been in such situations. What did you do? Well, sometimes when the code is more complex, and you just know that the variable contains the requested property, it might be tempting to cast:

Of course, we will satisfy the compiler here. But does that make our code any more safe than the previous version? Not at all.

In our example, based on the code we have written, TypeScript is not able to determine the exact type of variable. We can help it by using type guards. We will talk about them in details in a separate article. However, for now it’s enough to know that the language has some built-in type guards – one of them is typeof. Let’s use it in our function:

That’s cool, TS compiler doesn’t complain anymore. But how does it work? Our code is still accessing variable.length directly, there’s no casting there.

Notice what your IDE tells you when you hover your mouse over the variable in the first if branch after checking if the type is string:

and also what it tells you when hovering over variable in the else block:

Wow! The IDE magically knows what’s the exact type of our locally scoped variable! ?

This magic is called types narrowing. TypeScript compiler does many things to ensure that the type of local variable you work with is of the most specific type possible. It is based on the complex analysis of the source code, especially the code surrounding the place in which the local variable is used.

in keyword in types narrowing

Let’s take a look at this code now:

Let’s say we have a variable which may either be Employee or Manager:

In that place, TypeScript can’t say whether person is Employee or Manager.

Maybe you’ve used the in keyword for determining types before. Types narrowing also works with in keyword:

As you can see, TypeScript analyzed the flow, and it noticed that in the first if block we check whether the person object contains the employees property. If it does, the compiler known it must be Manager, not Employee. Cool, isn’t it? ?

Narrowing and equality operator

Another interesting application of TypeScript types narrowing is using the equality operator:

Notice how TypeScript determines the type of variables based on the === operator. If both parameters are equal, they must be both strings.

TypeScript types narrowing – summary

Narrowing in TypeScript is a very power feature of the language. I just showed you some simple examples, so you can grasp the idea and notice how much TS compiler does to ensure your type is the correct one.

If you’re interested, you can read much more about this in TypeScript docs. It’s however worth knowing how TypeScript compiler works and how you should properly check for types in your code. Remember that using any or explicit casting should be your last resort ?

The post How Does TypeScript Types Narrowing Work? appeared first on Yumasoft.

In this article, I’m sharing how this can be done ? It will also be useful if you use another testing framework than NUnit, but the examples are based on it.

Starting point

You can find the code accompanying this article here: https://github.com/dsibinski/cypress-csharp-example

Our starting point is a React application with Cypress tests:

I assume that your tests specs are placed within cypress/integration folder. The only spec we have is called submit_spec.ts and it placed in a subfolder called form.

Now imagine, that your backend is written in C#. Maybe you’d like to perform some data initialization before Cypress tests are executed.

In our case, we have a C# backend, and we’ve already had a mechanism for running integration tests. This mechanism runs our server app with an in-memory database, which makes the maintenance of tests very easy.

We wanted to use the same mechanism for our new, E2E Cypress tests. It means that we would be able to write some C# initialization code (data creation mostly) and then run Cypress tests from NUnit test.

What we want to achieve is to have a C#-Cypress NUnit test look as follows:

Let’s now see how we can implement the RunCypressTest method ?

Implementing a method to run Cypress tests from NUnit

To make things easier, let’s create a base class all our test classes can use. We’ll call it CypressTestsBase and add a RunCypressTest method to it:

This code does the job. Few interesting parts:

• Line 12 – I’m getting there the path to the web app workspace where npx cypress run command can be executed. It might be more complicated in your scenario, so you should adjust accordingly here
• Lines 13-20: thanks to setting RedirectStandardInput to true, we can later execute a custom command via cmd; setting RedirectStandardOutput to true allows us to write everything npx cypress run command does to NUnit test’s output
• Line 28: TestContext.Out.WriteLine(cypressProcessOutput); actually writes the Cypress output to NUnit test result
• Line 29: here we handle errors during Cypress execution. npx cypress run executed via cmd will return a code different from 0 if anything goes wrong.

We can now change FormTests class to run its corresponding Cypress test:

Finally, it allows to run our C# test, which then runs its corresponding Cypress spec and prints the output:

Cypress errors in NUnit result

Let’s see what happens if something is broken on Cypress/web app’s side. Let’s run our test, but with our web app not running.

The NUnit test fails, and we can clearly see what was wrong:

You will see similar errors if something goes wrong in a Cypress test. Cypress also saves compressed videos and screenshots, so if something goes wrong, diagnosing such failed tests is very easy.

Summary

I hope you found this article on how to run Cypress tests from NUnit useful. Remember that it not only works with NUnit – it will be suitable for any testing framework. You might need to adjust some parts of the solution, e.g. printing the results to the test result’s output.

This solution allowed us to improve our testing by adding a new type of tests to our pipeline. Right next to proper naming and mutation testing, E2E tests add another layer of security and improve the quality of our software.

Once more, you can find the complete source code here. If you want, feel free to copy it and change it according to your needs ?

The post Run Cypress Tests From NUnit Test (C#) appeared first on Yumasoft.

But what you actually want is the real object present there:

After reading this article, you will know how to achieve that ?

JSON.NET circular references are the issue

Let’s take a look at our problematic JSON response object once again:

$ref: "1" is basically a reference to another object, which has already been serialized. In that case, the BestFriend field references the first element of the result array with $id: "1". It turns out that these are JSON.NET circular references. However, you don’t want these references in your client-side JS code – you need the actual objects to work with.

I struggled with this issue some time ago in my JavaScript code. In the beginning, I had no idea it might come from the fact that JSON.NET is used for serialization (thanks to our colleague Rafał for pointing that out to me ?). Let’s see what exactly happens here and why.

JSON.NET serialization

The JS example presented above shows a JSON result received from the following ASP.NET controller method:

This is the full content of json string after serialization:

Of course, this is great that JSON.NET does that. Why would we repeat the same objects multiple times in JSONs? The optimization here is that the same objects are serialized once and referenced from all places that use them.

However, if such JSONs are sent to the browser, fields with refs are of no use. We need the actual objects to be there, so we can process the results correctly using JavaScript.

Solution 1: fix the issue by reconfiguring JSON.NET serializer

The first obvious solution could be to configure JSON.NET to not use its optimization for references. Quickly searching through its documentation, we find that PreserveReferencesHandling setting is responsible for that.

If we change our controller’s code and serialize objects with PreserveReferencesHandling set to None:

Our JSON file will look exactly as we’d expect:

However, why would we disable JSON.NET circular references? This optimization can sometimes save us huge amounts of data to be sent over the wire. If you have thousands of objects, it might not make sense in sending them all to the client-side code.

You may also have no control of the backend/API you receive the data from. It might as well be dangerous to change the JSON serialization settings, especially if you work on a big project.

If reconfiguration of JSON.NET circular references serialization is not possible in your case, see the other solution (which we also use).

Solution 2: resolve circular references using JavaScript

So we are back to this state in JavaScript:

What we want is to have the full objects’ contents instead of $ref elements in our JSON result.

In fact, all the data we need is already there. The first element of the array with $id: "1" is object that should be put in place of all $ref: "1" references.

As you can imagine, this requires a mechanism that would traverse the results tree and replace all these values according to IDs of the referenced objects.

Fortunately, we don’t need to implement it ourselves. There are few implementations of such a tool, circulating the web.

We use something called JsonNetDecycle which we found few years back already. I noticed there’s a new version of it ported to TypeScript: jsonNetDecycle.ts. It doesn’t provide full type support as it is a few years old already, and I didn’t try it. But you can if you use TypeScript ? There’s also a cycle.js solution available here and recommended by many folks. I believe it may also solve our issue, but again – this is not what we are using.

The version of the JsonNetDecycle we use is this one. Simply create a new file called JsonNetDecycle.js in your project and copy this Gist’s contents to this file. You can skip the last part starting with (function(console) (line 112) – we won’t need it.

Now, we can use the exported JsonNetDecycle.retrocycle() function to “fix” our JSON:

Let’s see whether this works.

This is what we get from the API before resolving JSON.NET circular references:

So we still have references there instead of real objects.

Now let’s see what happens with the result object after executing JsonNetDecycle.retrocycle() on it:

Wohhooa! That’s what we wanted ? There are no circular references in our JSON response anymore!

The post How To Fix JSON.NET Circular References ($ref) In JavaScript appeared first on Yumasoft.

Jest config

First, make sure that your jest configuration is correct. If you’re with TypeScript (and you should ?), I recommend using ts-jest configuration preset. Our config looks as follows:

If everything is fine, you should be able to execute npm test command (assuming it’s defined in package.json as "test": "jest") without issues. All your tests should be executed.

We now need to make StrykerJS working with that.

StrykerJS with jest configuration

If you install StrykerJS as described here, you’d expect that npx stryker run command runs mutations and everything is just fine. However, if you’re having wierd issues and errors with that, it probably means that Stryker is not properly configured to execute tests with jest.

When you run npx stryker run, it creates mutants (modifications in your source code) and runs tests against them. It means that StrykerJS must run your tests in the same way you run them. So, if you run tests with jest, Stryker must be able to do the same.

We struggled with many issues related to running StrykerJS with jest. Some of them were related purely to jest, but some of them to TypeScript as well. After numerous trial-and-errors and consulting with StrykerJS community members, we worked out a configuration that finally works fine for us.

Going straight to the point, here’s the stryker.conf.json file that would make StrykerJS work fine with jest and TypeScript:

To make it work, install the following npm packages: @stryker-mutator/core, @stryker-mutator/jest-runner and @stryker-mutator/typescript-checker.

Notice few important settings here:

• "checkers": ["typescript"] – this enabled a TypeScript checker plugin, which makes mutations being checked for types before running tests on them. It means that if a mutation introduced by Stryker doesn’t compile because of types issues, it won’t be taken into account for mutations (which makes perfect sense)
• “disableTypeChecks” – you still need to tell StrykerJS to not check types when compiling your code with type errors (mutants). It will compile them without types checking, but thanks to TypeScript checker plugin these ones will be filtered out for mutations
• "tsconfigFile": "tsconfig.json" – make sure to point to the TS config file you’re using here
• "concurrency": 4: this is another setting we experimented with to make Stryker working correctly. Without it, we were getting weird errors about lack of memory when running mutations (FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory)
• "testRunner": "jest" – this one enables the jest as our tests runner
• "jest" – here you tell Stryker to use your jest.config.js file we talked about at the beginning

With these settings, I hope that you are able to see this beautiful output of npx stryker run in your console:

StrykerJS with jest and TypeScript – summary

I hope this is helpful for you. StrykerJS is a developing framework, so some things are still hard to figure out. We believe mutation tests are a great way of improving our tests, so we use them on a daily basis. If you ever have any issues with StrykerJS, I encourage you to reach out to the community on Slack. They are extremely helpful there ?

The post How To Use StrykerJS With jest And TypeScript appeared first on Yumasoft.

and you’re looking for how to show their results in TeamCity as follows:

Then this article will help you configure that ?

Prerequisites

To run jest tests on TeamCity, you need to use jest as your testing framework of course ? If you use TypeScript – which I definitely recommend – ts-jest package will also be useful.

Having these packages installed, your basic jest.config.js file should look similar to this:

You should also have a test script defined in scripts section of your package.json file:

With this setup, you are able to execute your tests with npm test command and see the results in the console:

Such tests results are however not recognized in any way by TeamCity build server. Let’s see how to configure that.

Installing TeamCity reporter

In order to see the tests results in TeamCity, we need the npm test command to produce a different output when run on TC server. This output must be compatible with TeamCity’s service messages.

Fortunately, you don’t need to implement it by yourself ?

First, install jest-teamcity npm package to your project. Next, add jest-teamcity to reporters configuration option in your jest.config.js file:

Adding TeamCity build step

Next, login to your TeamCity server. You need to know the location of npm.cmd file on your TeamCity server. It should be in NodeJS installation catalog. In our case, the path to the file is C:\Dev\nodejs\npm.cmd.

Now, go to TeamCity web administration interface and create a new build configuration or edit a current one. Then, add a new build step:

Configure the new step as follows:

• Runner type: Command line
• Step name: Jest JS tests
• Execute step: If all previous steps finished successfully (or anything else you prefer)
• Working directory: name of the catalog in your web app where you normally run npm test
• Run: Custom script
• Custom script: “your_path_to_nodejs\npm.cmd” run test, for example: “C:\Dev\nodejs\npm.cmd” run test
• Format stderr output as: error

If everything is configured correctly, during the next build you should see jest tests output recognized and nicely reported by TeamCity:

If that’s not the case, make sure that TEAMCITY_VERSION environment variable is set on your TeamCity machine. That’s how jest-teamcity reporter recognizes when to output standard jest output and when to use TeamCity’s service messages format.

Debugging jest tests on TeamCity locally

If you run npm test locally, you will see that the output is still normal, not the TeamCity format. That’s correct, because as we said before, the TEAMCITY_VERSION environment variable must exist in order to see TeamCity-formatted output. Normally we don’t want to see TeamCity-formatted tests output locally, of course ?

It means that if you want to debug this configuration locally and actually see the TC tests output on your dev machine, you need to define such environment variable locally.

In order to do that in Windows, go to Edit the system environment variables, click on Evironment Variables... and add a new one in System variables section. Call this variable TEAMCITY_VERSION and give it some value, for example 2021.1:

If you’re on another operating system, add the environment variable according to your system’s requirements.

Next, restart Visual Studio Code or the console tool you are using and execute npm test again. Now you should see the tests results output in TeamCity format:

Jest tests in TeamCity – summary

I hope you found this piece of advice useful. At Yumasoft, we value tests a lot, both backend and frontend ones. However, the tests which are not run automatically are worth nothing. That’s why we always have all of our tests run automatically as part of our CI process (TeamCity in the sample project’s case).

The post How To Configure Jest Tests on TeamCity 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.

The problem

Let’s say that we install @ckeditor/ckeditor5-build-classic npm package to our web app. This is a kind of package that has many forks. Some companies or individuals fork ckeditor5-build-classic repository and create their own versions of it, adjusted for use with their products.

The problem is that if you use such a product that has their own fork of @ckeditor/ckeditor5-build-classic, you might want to use this fork as npm package, not the original npm library. However, in most cases there’s no npm package published for the forked repository.

We need a way to replace the contents (source code) of the original npm library with contents (source code) from the forked library (custom version). Let’s see how to replace npm library with our own code.

The solution

The first idea that comes to mind could be to create a modified private npm package and use it in our project. However, it requires some maintenance and forking the original library. We found a better solution.

If we go to node_modules folder looking @ckeditor/ckeditor5-build-classic package’s source, we can see that its source files (bundles) are present in node_modules\@ckeditor\ckeditor5-build-classic\build\ folder:

If you check some forks of this library on GitHub, there are also bundles present there, e.g. here or here. Let’s say that we need to take the forked version of ckeditor.js file and replace this file in our original npm library. How do we do that?

patch-package

To achieve this, we need to install patch-package npm package. This is an awesome, life-saving tool created just for what we need. Kudos to our teammate Przemek who recommended this gold tool to me ?

After installing the package with npm i patch-package, we can simply go to our npm library’s source and modify it. In our case, we replace node_modules\@ckeditor\ckeditor5-build-classic\build\ckeditor.js file contents with the contents of ckeditor.js file from our forked library (for example with this one). After that, we save the file.

The last step is to generate a patch for our original npm library. We do it by executing the following command: npx patch-package @ckeditor/ckeditor5-build-classic (replace @ckeditor/ckeditor5-build-classic with your package name). This is how it looks:

We can now see that a new folder called patches was created in our web app’s directory. In our case, it contains only a single patch file:

What’s interesting, this file is basically a git diff between the original and modified ckeditor.js files:

When we now execute npx patch-package command, the changes we’ve made before are applied to the actual npm library’s files:

This is great, because we can now add this command patch-package to our build script, so our custom changes to the libraries are applied on every build. It’s very quick and works like a charm. That’s how we managed to easily replace npm library with our own implementation ?

We should check in the patch files to our GitHub repository, so our teammates have them locally and our build server can also apply the patches.

Since this moment, we modified the npm library’s code, so everyone who imports and uses this library in our app will be actually using our modified version of it.

If needed, we can easily revert the changes with npx patch-package –reverse. It restores the npm libraries to their original versions (thanks to the patch file stored as git diff).

Summary

I hope you found this article helpful. You can use the patch-package library not only to replace the npm library’s source files, but also as a quick-fix for bugs found in these libraries. No need to wait for the open-source community to fix the issue or the PR to be merged. You can make the patch quickly and at the same time report the issue on the concerned package’s GitHub. The tool even offers a feature to create a GH issue in the original repo with the diff containing your changes by using command npx patch-package package-name –create-issue.

For us at Yumasoft, the patch-package is a life-saver. Maybe it also saves you some headache? ?

The post How To Replace npm Library With Your Own Implementation? appeared first on Yumasoft.

MDN web docs

The most recognized JavaScript resource is MDN web docs (MDN stands for Mozilla Developer Network) provided and maintained by Mozilla Corporation. While other programming languages usually have their official documentation, JS doesn’t have one (It actually depends od how do you treat ECMAScript, because it has official documetation). And the reason behind it is that a few teams worked on developing JS. But nevertheless, we have MDN web docs website, which is almost treated like official documentation for the JavaScript community. Information provided by maintainers is truly comprehensive. In my developer career, I have never experienced lack of crucial information on subjects of interest. What is more, this website provides sufficient tutorials for web development including JavaScript, HTML and CSS, divided into different levels of expertise.

Links:
MDN: https://developer.mozilla.org/pl/
Tutorials: https://developer.mozilla.org/pl/docs/Web/Tutorials

ECMAScript docs

ECMAScript was created to simply standardize JavaScript, because maintaining multiple independent implementations would be unbelievably hard without some sort of a standard. In ECMAScript docs you can find what JavaScript should look like and in almost every case it does. For example the latest official release of ECMAScript is named ES2020. Ecma international also provides information about future additions to the standard under the name ESNext. Technically the ECMAscript docs are the closest you can get to the official JavaScript docs. I personally wouldn’t recommend reading them for beginners, because complicated language and covered subjects might seem a little underwhelming.

Links:
Newest ECMAScript Docs: https://tc39.es/ecma262/#sec-fundamental-objects

Javascript.info

Javascript.info is a great and clearly made tutorial website. The tutorial itself covers JavaScript as a programming language and matter of working with a browser. The amount of information crucial to gain essential knowledge is perfect. I would say, if you want to maximize your learning speed, javascript.info is a right choice. In comparison to MDN docs, it is easier to get essentials and don’t get overloaded with information. Additionally, almost every topic has some bonus, usually it is some trick that is hard to invent on your own or explanation of unusual JavaScript behaviour. In my honest opinion, this site is the best way to start learning JavaScript – In my case it was a turning point.

Links:
Javascript.info: https://javascript.info/

Codecademy

Codecademy is an interactive learning site. You can take courses on a large amount of languages, but we are interested in JavaScript. If you are starting from scratch it is a way to go. Easy and well explained tasks will softly inaugurate you. The biggest advantage of this site is that you don’t need any code environment, you just write your code inside a special container right on the website. At the beginning, you already have some code written and you just have to change something or insert some variable or value, which sets the entry threshold really low. The downside of codecademy is “PRO” content, if you want to have access to everything, you must upgrade your account to PRO status and the lowest-priced upgrade costs 19.99$ a month.

Links:
Codecademy: https://www.codecademy.com/

Udemy

Video based tutorials have gained huge popularity in recent years. This form of studying is known as the easiest and really effective, so the huge increase in popularity is understandable. Udemy is a great online learning platform with a wide range of courses. It doesn’t only have videos, online tests, zip packages with source code and community conversations are a huge part of Udemy success. There are some free courses, but the better ones are paid. The prices are really high, but you can encounter 90% discounts almost every two weeks.

Links:
Udemy: https://www.udemy.com/

Some valuable udemy courses:
https://www.udemy.com/course/modern-javascript/
https://www.udemy.com/course/modern-javascript-from-the-beginning/
https://www.udemy.com/course/js-algorithms-and-data-structures-masterclass/
https://www.udemy.com/course/javascript-beginners-complete-tutorial/

Codewars

Learning by doing is pretty good, but if you ask me, learning by doing and competing is just amazing! Codewars is an online learning site, where you can complete challenges, get points for it and compare your solution to others. The challenges are divided into different levels of expertise and your account has a level itself to give you proper tasks. You can get better by completing challenges, but the amount of knowledge gained through studying solutions made by more advanced people is huge. Some code pieces you will find there will change your way of thinking and present you unthinkable actions. You can’t miss codewars!

Links:
Codewars: https://www.codewars.com/

W3Schools

W3Schools is an old-school tutorial page. You can start your web development path using this webpage, but you will run out of resources quickly. Topics are explained quite well for beginners, but explanations are simple and minimalistic. Lack of crucial topics are enough to say W3Schools is insufficient for more advanced people. Nevertheless, this webpage is worth checking.

Links:
W3Schools: https://www.w3schools.com/
JS tutorial: https://www.w3schools.com/js/default.asp

Youtube channels

It is an unlimited source of knowledge. You can find a huge amount of tutorials, explanations and examples on youtube. Some youtubers even upload some of their content from Udemy, so it is good to pay attention to several channels. I personally really enjoy crash courses on youtube, you can choose some technology and get essentials in under two hours.

Good channels:

Fun Fun Function: https://www.youtube.com/channel/UCO1cgjhGzsSYb1rsB4bFe4Q
Traversy Media: https://www.youtube.com/user/TechGuyWeb
freeCdeCamp.org: https://www.youtube.com/channel/UC8butISFwT-Wl7EV0hUK0BQ
Udemy Tech: https://www.youtube.com/channel/UCU6e4MJtvlcX5DBLP1cq8hQ
Academind: https://www.youtube.com/channel/UCSJbGtTlrDami-tDGPUV9-w
Dev Ed: https://www.youtube.com/channel/UClb90NQQcskPUGDIXsQEz5Q
The Net Ninja: https://www.youtube.com/channel/UCW5YeuERMmlnqo4oq8vwUpg
Techsith: https://www.youtube.com/user/techSithTube

Summary

There are a lot of javascript resources. They may vary within the quality, but all of them are worth trying. In my opinion, dividing your time into different resources gives the best results in the studying process, because you avoid monotony. I will try to pick the best choices in some categories and write them below.

Most comprehensive docs and tutorials: MDN web docs / ECMAScript docs
Most efficient tutorial: Javascript.info
Best for beginners: Codecademy

The post Resources to learn JavaScript appeared first on Yumasoft.