exellian / rex

About A efficient, flexible, simple framework for building reactive UI-components.
1 stars 0 forks source link

DRAFT: Template rendering function design #1

Closed exellian closed 1 year ago

exellian commented 1 year ago

A really important problem which needs to be solved is the design of the rendering function of a template. This function should not only render an arbitrary string instead it should be able to be used also for hydration and rendering a template to different objects. Therefore the function must be generated in a way that is very generic.

idea:

A template is built out of tree structure called Nodes (Tags, VoidTags, Text and Expressions):

<div>
{ 0 + 3 } // Expression
<div> //Tag with child nodes
  ...
</div>
this is the text of a text node
</div>

So each node is either a leaf (TextNode, VoidTag, Expressions) or a Node with children (TagNodes, Expressions). The real problem is that an Expression can not only be a leaf but also a node in this tree. In the following the individual cases are shown were Expressions are nodes with children:

<div>
{ <div> hallo </div> } // Expression which contains a tag with children. // Type: Node

{ // Expression which contains a for loop // Type: Array<Node>
  for x in 0..10 {
     <div></div>
  }
}

{ // Expression which contains a for loop // Type: Array<Array<Node>>
  for x in 0..10 {
      for x in 0..10 {
         <div></div>
      }
  }
}

{ // Expression which has an if block // Type: Node
  if success {
      <div>success!</div>
  } else {
      8 + 9 // Any other datatype which is not of type Node or Array<Node> gets automatically converted to a TextNode
  } 
}

{ (<div></div>) } // We could allow a Node inside a group, but this should probably discussed later on!

{ x.test } // 

So basically an expression embedded directly into the template can only have the type Node, Array, Array<Array>, Array<Array<Array>>, ...

Because we don't want to have different possible types of expressions the idea is to transform expressions in a way so that simply every expression has type Array. To do this we have to generate for every non Node expression a make_text_node statement, for every simply Node a make_vector_from_one_element statement, for every Array statement nothing and if we have a for loop expression, we have to perform a flat_map from Array<Array> to Array

exellian commented 1 year ago

Identifying the real problem:

The problem is that the function of creating an element currently just takes an array of Nodes as children, but this needs to be changed, because every child can not only be of type Node, but also of Type Array, Array<Array> and so on. To solve this problem we should introduce a Flattable trait which converts evert child of a node to an 1D-Array of nodes.

exellian commented 1 year ago

resolved in 3ef6de07abf7bdd2a012449e435ffc2ba85fe3ba