The reason of having hard times with values coming from an input sources (like an html form) is that you don’t have the exact data type beforehand. I mean, you can’t write functions using the input value which could benefit from TypeScript type system because an input value can be anything at that point, another function, a number, a string, an object, or whatever else. That’s why many programmers try to avoid types using the type called “any” in this case. …
The Composition API is a great way to share application logic between components in Vue.js. Not only can you organize repetitive snippets of code into separate files, you can also make them easily reusable.
The Composition API allows you to keep your variables reactive in shared snippets of code, which can be a huge improvement over implementations built in previous versions of Vue, even for enterprise-sized applications. According to official documentation, the deployment of the Composition API was necessary because efficient code sharing between components was a problem in larger applications.
Although there has been a solution to highlight common parts in the past, such as mixin, renderless compontent, or HOC, none of these could provide the same high degree of flexibility as the Composition API. The biggest advantage of this new feature is that we can simultaneously extract the parts that we previously had to implement in the data, computed, and methods parts for a given component (with the Options API). Let’s take a brief example of how to use the Composition API in real-world situations. …
I have worked in several different developer teams in the last eight years. All teams had both higher educated and lower educated members. I’m quite sure that you know what I’m talking about. I’ve noticed the following phenomenon: one of the most important kick-off task should be defining the coding style every time we start a new project.
Usually we have more than one alternates of writing some code snippet, especially in the script languages. I think we all have our favorites for a validator function, a controller or a DAO, or any other common parts. As an experienced engineer having best practices is a must, nothing wrong with that. But we have to form a team which means we have to adapt to each other’s habits without ruining the project. That’s why we need to define some rules BEFORE the work is started. The first rule is the coding style of the project. The coding style is nothing more than the form of our source code. …
In the last couple of years I used ORM (Object-Relational Mapping) in my Node.js projects a lot. Every time when I had to work with any relational databases I just grapped SequelizeORM to make my life easier. Unfortunately, even though Sequelize has TypeScript support according to its documentation, my experience wasn’t good at all with that. If you ask me, Sequelize is a great option in Node.js if you don’t use TypeScript, but I had to find a better option for my TypeScripted projects. Two day ago I read this library’s name somewhere: TypeORM.
I wish I had a library…
If you use Test Driven Development for your Node.js project uses Express library, you need to write unit tests among other things. As I experienced, testing code parts which use third party libraries are usually difficult for less experienced developers. The key aspect of effective unit testing is define boundaries of the business logic to be tested.
When I write unit tests including any structural items of the Express library, it produces me I have to avoid testing the library itself. It’s not my job. Rather than only my business logic needs to be tested. As for the middleware, it’s the logic inside the middleware function. …
MySQL has the latin1_swedish_ci as default charset but I need to set utf-8.
Append the following lines to the end of my.ini:
Now you have to restart the MySQL server to apply changes.