Define layouts in Dash.jl in same manner as Dash for Python and R

[rpkyle]

In Python, the app object has a layout method, for example:

app.layout = html.Div(children=[
    dcc.Input(id="graphTitle",
                     value="Let's Dance",
                     type="text"),

    html.Div(id="outputID"),

    dcc.Graph(
        id='graph',
        figure={
            'data': [
                {'x': [1, 2, 3], 'y': [3, 2, 8], 'type': 'bar'}
            ],
            'layout': {
                'title': 'Graph'
            }
        }
    )
])

In R, the syntax is nearly identical, with minor differences when declaring lists vs. dicts, and omission of dots within function names (e.g. dccInput instead of dcc.Input). In Julia, the layout is implicit when declaring the app object:

app = Dash("Test", external_stylesheets=["https://codepen.io/chriddyp/pen/bWLwgP.css"]) do
    html_div() do
        dcc_input(id="graphTitle", value="Let's Dance!", type = "text"),
        html_div(id="outputID"),    
        dcc_graph(id="graph",
            figure = ( 
                data = [(x = [1,2,3], y = [3,2,8], type="bar")],
                layout = Dict(:title => "Graph")
            )   
        )   
    
    end 
end

• We should add a way of setting the layout in Dash for Julia which mimics that of the Python and R versions, and separate this from the initial declaration of app.
• After refactoring to add layout, remove 🔪 layout_maker function
• Provide a layout_get method within the Dash struct in Dash.jl

[waralex]

In python layout is the property, not method! (the fact that it is implemented via setter method is not important from the point of view of the user interface). In R it is the method.
If we need a property I can convert DashApp struct to mutable struct, then app.layout = .... will work. But it will work with all another properties of DashApp too (I don't see that as a problem yet). I can also add function layout!(app, component) to setup layout. I would also add the overload layout!(layout_maker, app) to be able to use the do ... end syntax if the user doesn't like the hell of nested brackets as much as I do.
I also don't see the point in removing layout_maker from the constructor. I suggest just having two overloads of it - one as it is with layout_maker, the other without it.

If we can make the interface version as close as possible to Python and R, and also using the advantages of Julia to give additional features to the user, then why not do it?

[waralex]

In fact, maybe I can implement app. layout = ... without having to make the entire structure mutable, but this requires an experiment. So we need a choice - do we implement it as a property, or as a method,or both?

[rpkyle]

In python layout is the property, not method! (the fact that it is implemented via setter method is not important from the point of view of the user interface). In R it is the method.
If we need a property I can convert DashApp struct to mutable struct, then app.layout = .... will work. But it will work with all another properties of DashApp too (I don't see that as a problem yet). I can also add function layout!(app, component) to setup layout. I would also add the overload layout!(layout_maker, app) to be able to use the do ... end syntax if the user doesn't like the hell of nested brackets as much as I do.
I also don't see the point in removing layout_maker from the constructor. I suggest just having two overloads of it - one as it is with layout_maker, the other without it.

If we can make the interface version as close as possible to Python and R, and also using the advantages of Julia to give additional features to the user, then why not do it?

It's true that layout is a property in Dash for Python, and a R6 method in Dash for R. I think we should be pragmatic, and use whatever makes sense in Julia, while also trying to adhere to Dash idioms whenever possible. I agree that it makes sense to work within the idioms of a given language -- there are definitely idioms in Python that I wish existed in R, and vice-versa.

In this case, if a mutable struct will enable application developers to specify app.layout =, then I think that's a reasonable alternative. I'm not as comfortable with Julia as R, so I'm curious if you feel that there are fundamental issues with this approach.

If it's possible to provide the layout!(layout_maker, app) shorthand to abbreviate the layout declaration, while still supporting app.layout = , I don't see any problem with that personally.

As for layout_maker, I defer to @alexcjohnson -- my general perspective is that the constructors across Dash backends should be somewhat consistent, though there's no technical requirement preventing additions to the base API.

[waralex]

the constructors across Dash backends should be somewhat consistent

I agree with it. I think it's important that a person who has worked with Dash in Python can work with it in Julia or R with minimal cost.
But I also believe that if the features of Julia or R allow you to do something more convenient, or more familiar in the context of a specific language than in Python, then you should give the user this option in addition to the Base API

[waralex]

The following options are available in the master:

app.layout = html_div(...)
layout!(app, html_div(...))
layout!(app) do
    ...
end

div = getlayout(app)
div = app.layout

[rpkyle]

The following options are available in the master:

app.layout = html_div(...)
layout!(app, html_div(...))
layout!(app) do
    ...
end

div = getlayout(app)
div = app.layout

Great, I'm sure more experienced Julia users will appreciate the additional options you've provided, and app.layout = provides good parity with the Python implementation as well.

Thanks for taking care of these elements, I'm going to close this issue now! 🚀