v2.0.0

[fdoflorenzano]

This is an exciting one! This PR adds the current progress on Mechanic that allows a basic usage of custom inputs, interactive inputs, random seed history, and other tweaks and refactors across the app and the core functionality.

Two main general changes are introduced in these PR to make the previous aspects work.

First, the custom inputs are expected to be defined in a separate folder in a Mechanic project, inputs/ by default. In a similar manner as for design functions, Mechanic takes folders and imports every index.js inside all immediate subfolders. Because now new inputs could be defined, I had to go back and generalize and streamline how out basic input types are defined and loaded. Specifically, the code that validated the settings of each input used by a user now that to apply to this new cases, and it was stuck to our basic types. In packages/core/src/base-inputs you will find the definitions for all the basic Mechanic inputs, which also contain most of the expected exports in custom inputs. The code added into each HTML that then gets loaded in the iframe will validate that inputs exports look alright, and also that the inputs defined in the design function follows what each input sets of itself.

The other aspect general change was refactoring the code in the app and moved responsibilities between certain objects and agents in the whole execution flow. The random seed generation was moved to the app, so that the seed history could be easily tracked, input value validation is done outside of the mechanic object instance for simplicity, we started using immer to track changes in input values in the app so we could correctly detect value changes and correctly retrieve the last mechanic run without cyclical re-rendering.

You can find an example using custom inputs here. I thought of adding one into create-mechanic, but it doesn't currently support copying the whole project (including inputs), just functions, so we may have to update that too. Note that the example has yalc dependencies already added, so you can test locally as described here.

Initial commits are not very organized, since I was experimenting through multiple fronts at once trying to get stuff to work. Sorry about that! I also started using conventional commits in the hopes that we could eventually automatically create CHANGELOGS.

We can setup a call to check some of the specific, it's a bit much to explain all in one PR. Specially the specifics of custom import exports that we should go into the documentation.

Here's a copy of the main project CHANGELOG that summarizes the progress in this PR:

Added

• Custom inputs as components can be defined and imported into a mechanic project
• Custom inputs as interaction observers can be defined and imported into a mechanic project
• Random seed history, with undo and redo options and local storage persistency
• State can be set in mechanic instances and passed to the next instance through state and setState values
• Title in app shows open design function's name
• Not found page renders link to home

Changed

• Not found page is centered
• Loading and running errors are now shown in app as a modal instead of as an alert
• Uses immer to manage input values in app
• Generated script from function loader is now written in ESM
• Updated PostCSS dependencies: postcss-loaderand postcss-preset-env
• Generalized and streamlined input validation, and added basic inputs definitions and behaviors
• Renamed original width and height values passed from _widthOriginal and _heightOriginalto just _widthand _height.

Fixed

• Feedback tag gets lifted in UI
• Added array case to local storage input values serialization
• Allows nested URLs in app that redirect to first level of URL (to main design functions)

[fdoflorenzano]

I would suggest that we publish this as a 2.0-beta and then we all give it a try before releasing the big 2.0 update. How does that sound @fdoflorenzano? We're getting to the point in this project where the codebase is so big that the best way to Q&A it, is to have multiple people give it a try before releasing.

That's a very good idea! I hadn't consider it. I think it totally fits this scanario.

I'm guessing that the docs and the Q&A is the only thing we need to get this out into the world?

Yep! Should I wait for us to discuss both before merging and publishing the release?

[runemadsen]

@fdoflorenzano Up to you! I see no reason for not merging and publishing the beta :)