1189 julia components #1302
1189 julia components #1302
Conversation
…into 1189-julia-components
| Dash.register_package( | ||
| Dash.ResourcePkg( | ||
| DashBase.register_package( | ||
| DashBase.ResourcePkg( |
There was a problem hiding this comment.
Not new here, but is it important that this be two nested calls? Could it be refactored to just:
DashBase.register_package(
"{project_shortname}",
resources_path,
version = version,
[
{resources_dist}
]
)There was a problem hiding this comment.
@waralex points out we can do this later - not a major issue anyway.
| return result | ||
| available_props = Symbol[{component_props}] | ||
| wild_props = Symbol[{wildcard_symbols}] | ||
| return Component("{funcname}", "{element_name}", "{module_name}", available_props, wild_props; kwargs...) |
There was a problem hiding this comment.
FWIW on the Python side we could have used only kwargs like this but we chose to insert all the prop names explicitly in the signature (except wildcards of course) because it helps with autocompletion in IDEs. I have no idea if similar functionality exists in Julia, and anyway even if we do want to do this we can add it later.
|
@waralex this and plotly/Dash.jl#42 look great, pending a few minor comments. I thought we had solved the CI build problem you're seeing here, but @Marc-Andre-Rivet probably knows precisely what's going on (aside from the linter complaints, which you should be able to address easily via |
|
merging into #1197, will sort out the tests and give a final review there. |
Changes in generator to reverse dependencies.
Now the main components depend on DashBase, and the rest depend on Dash. I also took out the logic for checking parameters to DashBase and removed the generation of additional constructors if the component does not have the children property.
Corresponding Dash PR: plotly/Dash.jl#42