You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unify Component and VDOM Element Constructor Interface #755
Currently the vdom element constructor and component constructors have different interfaces. Component constructors are effectively just the same as the functions which define them. For the vdom constructor though we pass vdom(tag, attrs_dict, *children). The fact that these two constructors have different interfaces won't play well with this tagged strings PEP.
Proposed Actions
In anticipation of the work from the tagged strings PEP we should have a unified interface for constructing elements and components. I think the best way to do this would be to effectively copy the interface for React's functional components.
When constructing a component or element the interface would be:
constructor(*children, key=..., **attributes)
However the definition for the constructor would be:
In the function definition, *children gets bundled together into a special children argument that gets passed to the function. Component functions without a children argument then do not support *children. Additionally (as is currently the case) the special key parameter is hidden and handled separately.
One wrinkle in this is that the attribute for most user defined components will be snake_case while the attributes for standard HTML elements are camelCase. I suspect this will be confusing for most users. As a result, I suggest that, for standard HTML elements, we include a snake_case to camelCase conversion. Thus something like div(background_color) would be treated the same as div(backgroundColor=...).
This will be a relatively large change, so we will provide a way for users to transition to the new interface.
Notes
We should probably do #545 at the same time. So we'd add a fallback kwarg to the constructor:
I think I want to implement the conversion client-side since that's where they have to be interpreted, but the effect for the user would be the same - all attributes would automatically become camelCase.
It looks like there's approx 200 instances I'll need to modify. I drafted a script to auto-convert the old-style to the new one, but ast.unparse removes a lot of information (e.g. visually useful new lines) so I don't think I'll use it on IDOM's source:
I have an updated script that has much less impact on code style. I've run this script against IDOM's docs and tests to automatically convert html.*() usages to the new style.
Activity
rmorshea commentedon May 31, 2022
@Archmonger thoughts on this?
Archmonger commentedon May 31, 2022
I would recommend automatically changing all attributes from snake_case to camelCase on the backend.
I vaguely recall seeing some regex for this in Django core.
rmorshea commentedon May 31, 2022
I think I want to implement the conversion client-side since that's where they have to be interpreted, but the effect for the user would be the same - all attributes would automatically become camelCase.
Archmonger commentedon May 31, 2022
looks like there's a couple good solutions to this on the JS end as well
https://stackoverflow.com/questions/6660977/convert-hyphens-to-camel-case-camelcase
https://stackoverflow.com/questions/40710628/how-to-convert-snake-case-to-camelcase-in-my-app
rmorshea commentedon Nov 24, 2022
It looks like there's approx 200 instances I'll need to modify. I drafted a script to auto-convert the old-style to the new one, but
ast.unparseremoves a lot of information (e.g. visually useful new lines) so I don't think I'll use it on IDOM's source:rmorshea commentedon Nov 29, 2022
I have an updated script that has much less impact on code style. I've run this script against IDOM's docs and tests to automatically convert
html.*()usages to the new style.