@pro-script/as-is is a game changing library. Use cases 2.

For those who haven't read the first part, please head over to https://www.dhirubhai.net/pulse/pro-scriptas-is-game-changing-library-use-cases-1-volodymyr-kotov-nuuwe

Today, I want to continue unveiling the secrets of @pro-script/as-is, further exploring the capabilities of the 'as' methods.

This looks expected, readable, and safe. However, this code can be improved thanks to a clever feature in JavaScript.

This feature emerged back in the venerable year of 2016, meaning we could have been using it for the last 8 years. However, for some reason, frameworks have not fully harnessed the potential of this feature. Let's see how this feature works with the 'as' methods:

It's hard to believe, but you don’t need to invent new syntax to perform a simple type check. The existing syntax can do it easily and readably. Default parameter values are a cool feature if you find uses for them beyond the standard use cases.

However, there's one side effect. If a third argument is passed to the function, the check won't trigger, and then the third argument will end up in the variable lowdash. On one hand, your smart IDE might solve this problem by showing you that you’re trying to pass an extra argument. But you can easily avoid this situation by moving the check outside the parentheses:

You don’t necessarily need to use type checks inside an array or even within parentheses. All we need to do is invoke this method and get an error if the type check fails. The exact method of doing this doesn't really matter. You could simply make two calls to the "as" method separated by a comma. There’s no standard for this—use it however you like. Have fun, after all, this is JavaScript.

Now, let's deal with checking the type of a value returned by a function. Of course, you can tackle this problem head-on. Something like this:

The code remains readable; first, the value will be calculated, then it will be passed to the “as” method, which checks the type of that value. But to give you a preview, all methods in @pro-script/as-is are implemented using JavaScript Proxy, which means we can use not only the interception of the "as" method call but also intercept the Proxy set. Here’s what happens in this case:

Because we've intercepted the Proxy set, we now have the opportunity to eliminate unnecessary parentheses during argument initialization. And of course, you can still move the type check outside the parentheses:

The code now looks much lighter and remains readable. With @pro-script/as-is, you can create secure and easily readable code. You don't need to learn the syntax of another language or delve into the specifics of JavaScript itself.

When I finished implementing these two methods, "as" and "is," I saw the potential for creating interfaces. The pattern of using interfaces in development allows type checks to become reusable. You can define an interface once and then use it in many places in your code, avoiding the violation of the DRY (Don't Repeat Yourself) principle.

Unfortunately, simply using the "as" methods doesn't make this obvious:

It would be great, but unfortunately, we need to intercept the Proxy set on IArguments. Of course, you can do this yourself, and then your code will look fantastic. However, we create libraries to make our lives easier and to avoid writing the same thing over and over again. Moreover, since we've used the "as" methods throughout, it would be logical to use interfaces in the same way. Then IArguments would become as. IArguments. You probably noticed that in the examples where I import "as" and "is," I also import "Interface." Now it's time for it to shine:

No one is stopping you from moving the interface check outside the parentheses, just as was done in the example with the "as" methods:

Fantastic! It looks simply stunning! The code is highly readable, all types are checked, and we've even managed to protect ourselves from potential DRY principle violations. We've done a great job. As you can see, the "as" methods have proven to be quite flexible and powerful. But you haven’t yet seen the interfaces working at their full potential.

Please support this article with likes, shares, and comments. In the next part, I'll tell you more about interfaces and delve a bit deeper.