Board feature rework

thepaperpilot commented

2024-02-14 19:56:31 +00:00

Collaborator

Right now adding node types to boards with new displays (not a circle or diamond) is incredibly difficult. Theoretically the Board feature can just become a Vue component that gives the pan and zoom functionality to its children - including html children.

Then the diamonds and circles and lines could all be done by creating them like any other feature in profectus, and rendering them as a child within the Board component.

Selectability and drag and drop could then be done as decorators or some other way of augmenting an arbitrary component.

Other thoughts here: https://discord.com/channels/619613842141347841/848349393953882122/1114561906854854676

Right now adding node types to boards with new displays (not a circle or diamond) is incredibly difficult. Theoretically the Board feature can just become a Vue component that gives the pan and zoom functionality to its children - including html children. Then the diamonds and circles and lines could all be done by creating them like any other feature in profectus, and rendering them as a child within the Board component. Selectability and drag and drop could then be done as decorators or some other way of augmenting an arbitrary component. Other thoughts here: https://discord.com/channels/619613842141347841/848349393953882122/1114561906854854676

thepaperpilot commented

2024-02-14 20:08:57 +00:00

Author

Collaborator

I should be able to create a component that has no persistent state, has a hard-coded position and custom display.

I should be able to have a list of objects of arbitrary length that are all the same "type" but with individual persistent state. They get laid out automatically on the board, so their persistent state has no position (since it's determined by their index). It should theoretically be able to be re-organized by the player by swapping indices around, and doing that should not be any more difficult than the existing drag and drop system.

Perhaps all nodes should have a required position prop, and a utility function that takes an initial position (can be a function, to account for preventing overlaps or placing it near an existing movable node), and returns a persistent ref that can be provided as the position prop.
Should there be some abstract "BoardNode" interface that all features renderable inside boards need to implement?
Instead of just rendering their children, should Board components take an array of things to render as a parameter, for potential type safety ensuring everything has required properties (namely position)?

I should be able to have multiple list of objects of different types, each with arbitrary length, that have a persistent state including their position. Each type should be able to have a completely custom display that all nodes of said type use.

I want to keep the concept of "node types" because it makes persistence easier. Node types would be a property in the layer object - no need to be a child of some board feature, or siblings to any of the other node types. Indeed, there would be no need for a "type" field on the objects within these lists. There would just be a list, and it's location within the layer object makes it clear what "type" they are. The board knows to render them because they'd be passed into the render function along with all the other node "types"

I should be able to create a component that has no persistent state, has a hard-coded position and custom display. I should be able to have a list of objects of arbitrary length that are all the same "type" but with individual persistent state. They get laid out automatically on the board, so their persistent state has no position (since it's determined by their index). It should theoretically be able to be re-organized by the player by swapping indices around, and doing that should not be any more difficult than the existing drag and drop system. - Perhaps all nodes should have a required `position` prop, and a utility function that takes an initial position (can be a function, to account for preventing overlaps or placing it near an existing movable node), and returns a persistent ref that can be provided as the position prop. - Should there be some abstract "BoardNode" interface that all features renderable inside boards need to implement? - Instead of just rendering their children, should Board components take an array of things to render as a parameter, for potential type safety ensuring everything has required properties (namely position)? I should be able to have multiple list of objects of different types, each with arbitrary length, that have a persistent state including their position. Each type should be able to have a completely custom display that all nodes of said type use. - I want to keep the concept of "node types" because it makes persistence easier. Node types would be a property in the layer object - no need to be a child of some board feature, or siblings to any of the other node types. Indeed, there would be no need for a "type" field on the objects within these lists. There would just be a list, and it's location within the layer object makes it clear what "type" they are. The board knows to render them because they'd be passed into the render function along with all the other node "types"

thepaperpilot added this to the Profectus project 2024-02-14 20:18:03 +00:00

thepaperpilot referenced this issue

2024-10-24 09:44:51 +00:00

Board rework #26

thepaperpilot referenced this issue

2024-12-26 17:08:27 +00:00

Implement Board and Feature Rewrites #88

thepaperpilot closed this issue

2024-12-26 22:24:51 +00:00

Rows
Columns

Board feature rework #62