The component/ directory is very messy after previous refactor on the Editor component. This issue will serve as a small reminder to organize the directory

After #21, it is clear that the business logic has been extracted out also.

As a reminder, persistent states used can be extracted and abstracted away into their own custom hooks. The solver and calculation section has to be updated also, but I will keep in mind to not go over the scope of the issue.

This enhancement should be easy to implement on the calculator part, but the difficulty will surely come from collecting and keeping the images up to date with the game. I hope I will have that kind of time soon.

Add options to change the change the displayed units on the calculator:

• from item per minutes to items per second
• from MW to GW and kW

Project structure refactor

I recently came up with a nice project structure and I would like to apply it to this project. I consider this project to be on a larger size in scale, so the restructuring work should be interesting.

Using TypeScript path aliases, there will be a separate directory for each core part of the project;

• core/ for business logic,
• database/ for handling with recipe and item data
• component/ for front end UI component
• types/ for types and interfaces, every type and interfaces should be here except for component props definition

On top of computing the desired production targets, an option to compute an optimal layout from available materials.

A potential behavior could be:

• Every field of the material must be filled to perform the computation.
• If a material capacity is unset, assume it has zero transport capacity and skip calculation.
• When both material capacity and desired production target are set, material capacity takes priority.

Enabling and disabling features with flags were difficult to work with, should be careful about the implementation.

As of current release v2.1.0, the explanation on each field on the "Layout" card is not clear and causes confusion. This problem should be solve with user manual.

The last feature to complete this project is an option to build a dynamic blueprint. It is clear that blueprints in Dyson Sphere Program is an encoded string along with some metadata. The metadata is comma-separated, and the actual blueprint information is present as the payload.

Reversing engineering the blueprint encryption and decryption will undoubtedly be the most time consuming part of this feature.

Integrate indexeddb as primary database

The recipe data is bundled along side the source code itself. I will move data storage to indexed database. The goal is not a noble effort to reduce the strain on the network, but rather I would like to give myself an opportunity to implement a "migration-like" system within the database of the project.

Add an option to share the current workspace as a link, similar to Factorio Lab's.

Move "Desired production" section from the configuration over onto the primary display. Using tabs the input-oriented setting will be called "Production constraint" and "Production capacity" for output-oriented calculation.

To accommodate for input-oriented calculation, the entire solver module has to be rewritten.