VS Code and Node.js

Install Node.js from official web.

Nodemon

Install nodemon:

1. npm install -g nodemon

launch.json

1. { "configurations": [ { "console": "integratedTerminal", "internalConsoleOptions": "neverOpen", "name": "nodemon", "program": "${workspaceFolder}/qetrix.js", "request": "launch", "restart": true, "runtimeExecutable": "nodemon", "skipFiles": [ "<node_internals>/**" ], "type": "pwa-node" } ] }

When I debugged the router and module init, I wanted to run it immediately after nodemon restarted, so simply I added a HTTP GET call right into server.listen function:

1. http.get("http://127.0.0.1:3000/subject");

In VS Code you don't even need to hunt for extensions, “Node Debug” is already built-in.

I have to admit, it's quite joyous to work like that. I really like the simplicity of PHP and this isn't actually that far off.

asdf

Subjects

With the team we finished a module for subjects (people and companies). We were hoping to get a shortcut, but the customer disagreed :-), so in the last months of many improvements and fixes I was forced to add a lot of technical debt to the codebase.

Another setback was the customer is still using IE11 and the original Edge, which added more complexity to the code, as various polyfills were required and also separate stylesheets, because there's no way to distinguish between the two using just media queries:

1. IE11:
2. @media all and (-ms-high-contrast: none), (-ms-high-contrast: active) { ... }
4. Edge:
5. @supports (-ms-ime-align:auto) { ... }

This was our first deployment of QedyJS, where we gathered awful lot of experience, and also the module is only a temporary solution for the customer, because he contracted another company, that are unable to provide their solution at the moment for legal reasons.

So I took the opportunity and created basically a working “demo” of what the final version of QedyJS should be capable of, only without all the hacks, tweaks and crutches. It's always easier to think of what to do differently, than what to do. This demo became a foundation for the Mk. III announced back in January and was largely enhanced since – Mk. IIIb, if you will.

There were some approaches I didn't like, some of them didn't work, some of them were sub-optimal, some of them was proven and will be kept, some of them were introduced for the first time and some of them were put aside for the time being.

I gathered all of the above and started once again with a clean plate. This time not as my primary project, but rather as a side project to pamper and enjoy. I wanted to have the time to do it really properly, to be able to elaborate on ideas, to have an incubator for them.

Comp-Elem Modes

There are six basic modes for components:

• *hidden*: component is not in DOM and therefore not visible to user;
• *plain*: component (rather it's text or value) is represented by plain text;
• *inactive*: component is read-only or disabled, but as a form control;
• *normal*: component is an editable form control;
• *expected*: component is marked as "expected", which is just visual distinction and overall works just as “normal”;
• *required*: component is required to have a value before form processing.

To make things easier, if you need to set a particular mode to multitude of elements, you can simply set a mode to their parent component, instead of every element separately.

But there are cases, in which you probably don't want to override the mode: if you have an element defined as inactive, like a computed value, you don't want it to suddenly became required. And if it's hidden, it should stay that way.

From such rules emerged the following table:

Results of mode overrides by component (rows) for elem modes (columns).

I did several tests and it works as expected. If your expectations are different, you can always set mode directly to elements and omit using bulk mode assignments via parent components.