Code Validation
· Andrew Lisowski
One thing that representing your code as a graph of values unlocks is far more incremental builds. Packages, files, folders and apps are a poor way to tell whether a piece of code needs to be checked again.
Traditional JS
An app might be split into packages like these:
core/: shared functionality for the appscomponents/: frontend UIapps/dashboard/: an internal dashboardapps/client/: the user-facing UI
Whenever anything in core/ changes, everything that depends on core/ has to be rebuilt, re-linted and re-tested.
Here that means validating every bit of code, even code that didn't change and doesn't use anything that did.
Values in tcm
In tcm, your code isn't organized into packages, files or apps. Each value is stored individually, and the imports between them form a graph. From that graph, we know exactly which code needs to be validated again.
Represented as a graph, the example above might look like this:
SomeTypesomeArrArrayRendererUserRendererDashboardAppClientApp
If we change someArr, we know exactly what needs to be validated again, and everything else can be skipped.
Build Superpowers
In traditional projects, it's very easy to introduce dead code (code that isn't used anywhere). Dead code makes your project bigger and slower. With tcm, it never gets there in the first place.
The graph does away with a lot of the complexity of the past:
- Dead code elimination: code that isn't connected to the graph just isn't included.
- Tree shaking: there's no need to shake out what isn't referenced.