Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User library #42

Open
passiomatic opened this issue Jan 11, 2022 · 0 comments
Open

User library #42

passiomatic opened this issue Jan 11, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@passiomatic
Copy link
Owner

passiomatic commented Jan 11, 2022

It can be convenient to save a node/group of elements for later. The idea is to allow the user to select a document element, name it, and save into a "user library", which is a particular section of the element library.

A user library item could be also reused in the codegen phase, by referencing it instead of duplicate its code over and over. This is probably the most straightforward way to allow some code reuse/structure in the generated code.

One interesting extension of this process could be the ability of alter the original document element and reflect changes to the "replicas" of such element. This mirrors similar concepts found in Figma or Sketch (Components and Symbols respectively).

In Elm we can think about it as a "view function": define once and reuse multiple times.

Implementation

Currently library has a default number of primitive elements, which mostly maps 1:1 with Elm UI functions, stored in Library.elm. The idea is to enrich such library at runtime, maybe using a List field in the model, and add more document nodes when user needs it. Every new node becomes a LibraryItem when added into such list.

Elm Designer already knows how to transform a LibraryItem into a Tree Node when use drags it into the workspace, and these new nodes are no exceptions.

So, if we want to implement the original-replicas scenario described above we need a way to discriminate the concrete, original elements and the replicas. We could turn Node into a custom type:

type Node 
  = Original NodeData
  | ReplicaOf NodeId 

While traversing the document for rendering we need to handle both custom type variants, and with replicas we need look up the data for the original one, including its children - because a replica doesn't have any content.

When a replica node is selected you can go back to its original node and edit it.

Visually there's should be an obvious way to tell apart a replica from an original node. Maybe we could mark the selection border with a different color and add a little label showing the library item name.

User library must be persistent, and for now we can save it within the current document. Ideally they should be tied to user, and available cross-documents.

Notes from Slack

Georges Boris

  • maybe this should lock the view in its own space and if the user wants to edit it it needs to open the block view. any changes will impact all blocks. the user cannot select a single piece of this block after it is grouped unless they are inside the block edit view.
  • with this, you could add fields to the block that would be the only updatable things appearing on the right pane when the user selects the block.
  • inside the block you could access those fields values through some placeholders perhaps?
  • if you want to break out of the block somewhere you just copy the current contents and make them static again.
@passiomatic passiomatic added the enhancement New feature or request label Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant