DEV Community: Varlen Pavani Neto

Considerations about implementing VueJS systems

Varlen Pavani Neto — Wed, 01 Dec 2021 19:59:34 +0000

When working with VueJS, I feel productive and feel like my code is explicit about what it is doing. It works nicely with current Web Standards and also lets you bring your own tooling if needed.

In comparison with Angular, Vue gives the developer total freedom on how to architect the application frontend, only being concerned about rendering components on screen (the view, or le vue). There's no such thing as Modules, Services, no RxJS or anything like Angular provides by default.

This freedom simplifies the implementation but comes with a cost. If your project is heavy on the logic side of backend or has multiple components, it is necessary to expend some time to keep the house clean, organize everything and define standards to be used with the team.

It may be a little bit confusing for newcomers to know how to organize your implementation and over time I found myself taking some notes about this, to be able to improve how Vue systems are built.

Here, I want to share some of my insights, gathered from the experience of working with many distinct VueJS systems, some started by me, some started by others, and also from the experiences shared by coleagues.

Do NOT use Vuex without reason

Vuex is the default Global State management solution in Vue. It is part of the study path of any Vue training. It is fair to say that Vuex was inspired in Redux.

However, it is easy to misunderstand when to really use it. I've seen projects that used Vuex in every single API call, even when that specific store was used by a single component.

I've seen developers hating Vue mostly because every single API call would yield way more lines of code that needed. That's not Vue fault, but Vuex misusage.

Some may argue that "I will create it because whenever you create another component that uses it, the state is already there to be used". Well, it is true. However, you cannot predict the future to be really sure that the added complexity of Vuex will pay-off.

I believe that it is better to supose that YAGNI (you ain't gonna need it). Let the state sit in the component and just move it to Vuex if you really think this is necessary. Prefer props and events to comunicate between components.

If your team comes from an Angular background or you're reusing parts of a previous system implemented in Angular, you may also ditch Vuex entirely and give a chance to vue-rx, which allows to use subscriptions as a property of a Vue Component.

Pure Components and High-Order Components

There are two concepts that come in handy to organize the Vue code.

First is the Pure Component. The Pure Component is a component that doesn't have any external API calls (using axios, a service or whatever) or directly access the global state (the Vuex stores, possibly). This is ~~an idea stolen~~ slightly inspired in Pure Functions, from Functional Programming.

For instance, suppose that you have a component that renders a table of data with a single text input on top that filters the displayed content.

Also, suppose that your system have many pages, displaying different domain entities in each page, but using that same table component with different configurations, like column headers.

If you use a component library like Vuetify, you may use its v-datatable component to do the job. But, at some point you'll probably realize that most code to setup the datable is being repeated across multiple pages.

At this point it is a good idea to create a Pure Component wrapping the v-datable, let's call it, for example, FilterableTable. Now, all your shared code lies in a single place and you can use the FilterableTable in the pages without repeating all the required configuration.

The FilteredTable component does not fetch any data and must receive data to be displayed somehow. From this, we notice that we'll need a parent component passing data to the props of FilteredTable and listening to its events.

This parent component is a High-Order Component. It is a container of Pure Components. This is the right place to fetch data from APIs or consume services and to access and mutate the global state.

A High-Order Component may have multiple Pure Components and orchestrate them if necessary.

This separation between Pure Components and High-Order Components allows developers to keep components small and makes it easier to understand and maintain.

Don't fear the Props

Props in Vue can be typed and validated. This is extremely useful, specially if the project do not uses typescript, for creating Pure Components and sparing some lines of test code. Trust Vue to do the validation for you.

Props do give you the possiblity to pass a whole object into a Vue component. This is something that should be done with caution.

Do not assume that the deep properties are available when your component is created and rendered unless you ensure that manually, otherwise you will face some errors and broken page renderings.

Vue will try to reach properties that still doesn't exists when creating the component and throw an error.

One useful pattern to solve this problem without needing to validate every single object property used by your component is to ensure that the component is only created when data exists or after loading with v-if.

If all the component needs is a small subset of object data, a couple to a few properties, prefer passing these as single props instead of the whole object. This will give you the advantage of validating each property individually.

Avoiding Big Components

The number of rows in a component may be used as an indication that the component could use some refactoring and may be simplified.

There's no fixed value for that but as a rule of thumb, I would say that a component with 100 lines is ok, 300 lines is ok-ish, 600 lines is a yellow light and 1000 has a considerable probability of implementing multiple concerns that should be separated.

There are some strategies that may be useful to refactor a component into smaller parts.

First, start by analysing your methods. Sometimes you may have a single method that just changes the value of a state variable (those in data object). In this case, you may replace the method with the attribution itself in the places where the method is called.

Methods in Vue Components usually are not meant to be used as methods in default object oriented scenarios. The main difference is that Vue Methods are usually used inside the component itself to do a single internal operation and not as a gateway to the external world which would be the case that would justify a method with a single line in object orientation.

Thus, the use case for methods in Vue is closer to private methods in object oriented languages and if this detail goes unoticed, it may lead to unecessary creation of methods.

If a component needs to comunicate with the external world, then the proper way to do it is using props to receive data and events to output data, considering a pure component.

Specifically if you have a component with let's say, 1000 lines, it certainly could be refactored into a High-Order Component plus a few Pure Components and Mixins.

Be aware of Mixins

For last but not least, about mixins I have the same advice from Vuex: Use carefully.

Even seeming like a great solution for code reuse, they may create unwanted coupling between components if misused, leading to maintainability issues.

Definetely, avoid having multiple mixins in the same component to avoid name colisions.

A interesting use case for Mixins is to keep pre-made event handler methods that will be used in a High-Order Component.

Thank you!

If you find these insights useful or want to share some more, feel free to leave a comment or reach me out on twitter at varlenneto.

PS: A big shout out for all people that took their first look on Vue influenced by me. You folks were the inspiration for this post

Productivity on Visual Studio Code - Running scripts from keyboard shortcuts

Varlen Pavani Neto — Thu, 13 Aug 2020 01:19:58 +0000

Have you ever dealt with some scripts that you need to run over and over again via command line in a project? Some redeploy script, custom compilation or something?

I was working on a project where it was necessary to recreate the database from scratch in a docker container every few moments and it was really boring to invoke the rebuild script by hand on the command line every time I changed its creation script. Here I share a simple tip that increased my productivity and development experience considerably.

Instead of typing the command in the CLI or right clicking it everytime it was needed to run it, it is possible to create a task and add a keyboard shortcut to it.

By doing this, we don't need to access the CLI to invoke the script anymore. It is even possible to make coffee (taken from here) with a keyboard shortcut without leaving Visual Studio Code! The only thing is that you will need a compatible coffee machine in your network :)

To create a task, open Visual Studio Code command pallete and search for

> Tasks: Configure Tasks

Then choose

Create tasks.json file from template

and pick one of the available templates, according to your needs. For example, I will use Others template:

This will create the .vscode/tasks.json file, allowing you to configure tasks.

It is possible to do all kinds of stuff using Visual Studio Code tasks and you can find the full documentation here.

Now edit your tasks.json file to include your script in a object inside the tasks array:

{
   "label" : "my nice task",
   "type" : "shell",
   "command" : "./myscript.sh"
}

After creating the task, you can version this file in your repository to share this configuration with other developers.

Now if you open the command pallete again and select Tasks: Run Task, you will be able to see and run your task from there.

Now, it is necessary to configure the keyboard shortcut.

Open the command pallete (Ctrl+Shift+P or F1) again, type in "keyboard" and look for Preferences: Open Keyboard Shortcuts (JSON)

This will open the keybindings.json file. You can version or keep this file in a (gist)[gist.github.com]. There, you can define a new keybinding by clicking in the button on the bottom right or type in manually the configuration:

{
   "key": "ctrl+k 1",
   "command": "workbench.action.tasks.runTask",
   "args" : "my nice task"
}

Let's look what each parameter does:

key : This is the sequence of keys that will be used to trigger your script. From the configuration in the example above, it will be necessary to press ctrl and k simultaneously and then press 1 (This is what is called a "chord").
command : This is the reference (command id) to the internal command of Visual Studio Code that will be triggered by the keypress. Here, it is the command that runs a given task. The full list of commands can be found by opening Default Keyboard Shortcuts (JSON).
args : This is an argument to the command. In our case, it is the exact name of the custom task.

Save the keybindings file and you're good to go. Try pressing the key sequence that you just configured.

There's a lot of customization options for keybindings and if you find it useful, I highly recommend checking out the docs on this feature of VSCode as well.

Editing MIDI files with Python

Varlen Pavani Neto — Sat, 11 Jul 2020 01:10:25 +0000

Couple months ago, I was in the house of my band's guitar player doing pre-production of a new song. Our drummer had sent us a MIDI sequence made with MT PowerDrum Kit 2 VST plugin. I wanted to check how the grooves would sound with a sample pack I had.

I tried to load the samples using Kontakt and...

The sample pack had some sounds mapped differently from the original plugin. What now?

I could edit the drum line note by note in my daw, however this is a tedious and error prone process. Besides, if my drummer send me another version, I would need to change everything again. Manually.

We can create drum lines using one plugin and use it in another. Here I show you how to avoid the repetition and automate the translation between different drum plugins using Python.

MIDI and MIDI files

MIDI is communication protocol created way before my existence in this planet. In a nutshell, it empowers musicians by allowing multiple digital musical instruments to work together.

Usually, MIDI devices used a 5 pin DIN cable. Nowadays, the protocol still exists and is commonly found working over USB, connecting instruments to a computer.

MIDI uses messages to communicate events like the start or end of a note, its intensity and pitch, a change in tempo, etc.

These messages can be stored in a MIDI file. These files were famous on the early days of multimedia internet as background music for personal websites and as polyphonic ringtones.

These files can represent digitally the performance of a song.

How to handle MIDI files?

We could search the MIDI protocol specifications and implement the protocol ourselves, however since the idea here is to avoid a lot of manual work, a quick Google search for a library may be enough.

By googling "python midi library", I found mido. From skimming the docs, we can see that it should provide everything we need for this task. It is available here.

Pip provides it:

pip install mido

Thinking about the script

Having our tools chosen, we now need to plan what the code must do.

The python script must read note sequences in the source MIDI file and map each note from the original plugin into their equivalents of another plugin.

For that, it is necessary to understand how each VST plugin maps their drum pieces into MIDI notes. For MT PowerDrum Kit 2, there are some files in their website documenting which note maps each sound.

The sample pack had these informations in its PDF manual.

It would be really convenient to do this mapping in a visual way, but I didn't find any tools for doing it, and creating a custom tool would go totally against the purpose of this whole thing. (It could be a nice side project, thou)

Since, there's no another way to do it, I did it by hand, trying the best match possible between both plugins.

Each row contains source, destination and description columns.

If you find yourself doing the exact same mapping, don't waste your time anymore, here it is:

65,44,Hihat Pedal
63,68,Hihat Edge Tight
62,69,Hihat Edge Closed
61,71,Hihat Edge Semi-open
60,72,Hihat Edge Open
58,54,Crash 1 Choke
57,55,Crash 1
55,55,Splash -> Crash
53,53,Ride Bell
52,35,China
51,51,Ride
50,50,Tom 1 - Hi
49,52,Crash 2
48,50,Tom 1 - Hi
47,48,Tom 2 - Mid
46,72,Hihat Edge Open
45,48,Tom 2 - Mid
44,71,Hihat Edge Semi-open
43,47,Tom 3 - Low
42,69,Hihat Edge Closed
41,47,Tom 3 - Low
40,38,Snare
39,38,Snare
38,38,Snare
37,37,Sidestick
36,36,Kick
35,36,Kick

Here's the final script, commented line by line:

from mido import MidiFile, MidiFile, MidiTrack

# Opening the original MIDI sequence
input_midi = MidiFile('./Murundu.mid')

# Creating the destination file object
output_midi = MidiFile()

# Copying the time metrics between both files
output_midi.ticks_per_beat = input_midi.ticks_per_beat

note_map = {}
# Load the mapping file
with open('note_map.csv') as map_text:
    for line in map_text:
        elements = line.replace('\n','').split(',')
        # Each line in the mapping file will be loaded into a
        # dictionary with the original MIDI note as key and
        # another dictionary with target note 
        # and description as value
        note_map[int(elements[0])] = { 
            'target_note': int(elements[1]), 
            'description': elements[2] }

# Now, we iterate the source file and insert mapped notes
# into the destination file

# Notes are determined by note_on e note_off MIDI messages
# Other types of messages will be copied directly 
# Notes that does not exist in the mapping will not be copied

for original_track in input_midi.tracks:

    new_track = MidiTrack()

    for msg in original_track:
        if msg.type in ['note_on','note_off']:
            # mido's API allows to copy a MIDI message
            # changing only some of its parameters
            # Here, we use the mapping dictionary to create
            # the mapped note, keeping its properties like
            # intensity

            origin_note = msg.note

            if origin_note in note_map:
                new_track.append( 
                    msg.copy( note = note_map[origin_note]['target_note'] ))
                print(note_map[origin_note]['description'])
            else:
                print("Origin note",origin_note,"not mapped")
        else:
            print(msg.type)
            new_track.append(msg)

    # MIDI files are multitrack. Here we append
    # the new track with mapped notes to the output file
    output_midi.tracks.append(new_track)

# Finally, save the mapped file to disk
output_midi.save('./Murundu-remap.mid')

Thanks for reading!