Revamp Processor

[ianjosephwilson]

• Revamp Processor To Be Template Based
  • Enumerate interpolation cases to simplify logic and establish framework to hone correctness, specially around text types.
• Remove Nodes
• Move svg support into processor.
• Add in system context, parent tag context and namespace context. Needs another PR.
• Change Component Signature(s)

def FunctionComponent(children: Template, **kwargs) -> Template:
    return t""
def FactoryComponent(children: Template, **kwargs) -> Callable[[], Template]:
    def ComponentCallable() -> Template:
        return t""
    return ComponentCallable

• Change Component Children Processing Order
  • Children is a Template so the actual contents are not processed until after the component is invoked.
• Change Content Interpolation Rules
  • Zero-arg functions no longer have special treatment:
    • to_html(t'<div>{(lambda: "dynamic")}</div>') != '<div>dynamic</div>'
    • A new formatter named callback can be used which then interpolates the return value
      • to_html(t'<div>{(lambda: "dynamic"):callback}</div>') == '<div>dynamic</div>'
  • Boolean values no longer have special treatment We'll keep this for now.
    • True/False are both ignored.

[davepeck]

Thanks @ianjosephwilson for this updated PR! I hope I've done a good first-level job at explaining my perspective here...

[davepeck]

One last comment:

Boolean values no longer have special treatment

I think we need to support this, mostly for familiarity from anyone arriving from Javascript-land. {someCondition && <div>...</div>} is an extremely common idiom.

[ianjosephwilson]

One last comment:

Boolean values no longer have special treatment

I think we need to support this, mostly for familiarity from anyone arriving from Javascript-land. {someCondition && <div>...</div>} is an extremely common idiom.

Fine, I think it is a small mistake, but we can hopefully make it configurable later on.

[ianjosephwilson]

Some diagrams showing the call structures:

TElement, TFragment and TComponent

graph TD;
    process_tnode-->_process_element;
    _process_element-->process_tnode;
    process_tnode-->_process_fragment;
    _process_fragment-->process_tnode;
    process_tnode-->_process_component;
    _process_component-->process_tnode;

Loading

TText (Raw) and TComment

graph TD;
    process_tnode-->_process_raw_texts;
    _process_raw_texts-->resolve_text_without_recursion;
    process_tnode-->_process_escapable_raw_texts;
    _process_escapable_raw_texts-->resolve_text_without_recursion;
    process_tnode-->_process_comment;
    _process_comment-->resolve_text_without_recursion;

Loading

TText (Normal)

graph TD;        
    process_tnode-->_process_normal_texts;
    _process_normal_texts-->_process_normal_text;
    _process_normal_text-->_process_normal_text_from_value;
    _process_normal_text_from_value-->_process_normal_text_from_value;
    _process_normal_text_from_value-->process_tnode;

Loading

Node Processor

graph TD;        
    _resolve_t_node-->_substitute_and_flatten_children;
    _substitute_and_flatten_children-->_resolve_t_node;
    _resolve_t_node-->_invoke_component;
    _resolve_t_node-->_resolve_t_text_ref;
    _resolve_t_text_ref-->_node_from_value;
    _invoke_component-->_node_from_value;
    _node_from_value-->_node_from_value;
    _node_from_value-->_resolve_t_node;

Loading

[pauleveritt]

I've moved my stuff away from Node and over to this PR. Including context. I currently have around an 80 line "fork" override to enable calling components.

If I could get a "hook" plug point, I could eliminate it. I (with Claude) have a writeup I can provide.

[ianjosephwilson]

@pauleveritt What do you mean "enable calling components"? I think components should still work, although this roller coaster of pull-requests has been changing a lot. I'm sorry. I have been thinking about your attribute rewriting situation. It is similar to the "svg" attr fix situation in a way and there seems to be emerging behavior that resembles these sort of single level (1-node/1-node's children) change of behavior or multiple level (subtree) change in behavior. I think there should be some sort of pluggability in there but I'm not sure what/where at this point. Maybe that is for another PR ?

[pauleveritt]

I have a DI system that changes the way components are called. I'd like to configure a function I can provide that handles the calling of a component. The function should be provided the target and have access to the contextvar.

I have a long analysis of this (via an agent) with a lot more detail.

No rush, as my "fork" is now rebased on this PR.