Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved demo project architecture? #58

Closed
brylie opened this issue Oct 29, 2018 · 6 comments
Closed

Improved demo project architecture? #58

brylie opened this issue Oct 29, 2018 · 6 comments
Labels
Stale Issue has aged and is now stale

Comments

@brylie
Copy link
Contributor

brylie commented Oct 29, 2018

The Django architecture encourages developers to separate code into separate files, such as models, views, settings, etc.. Similarly, it would be cleaner to architect Dash apps in a more Django-esque manner, by separating out the app, layout, callbacks, etc into separate files. An example of this type of architecture can be see in the slapdash project layout.

How can we architect django-plotly-dash projects to have clean separation of code? Specifically, how can we put callbacks and layout into separate files from the DjangoDash app instance?

@eddy-ojb
Copy link
Contributor

eddy-ojb commented Oct 29, 2018

Hi brylie,

I agree with the idea but I like that the demos mimic the simple Dash tutorials as much as possible. Perhaps turning the demo in to a django project with "simple app" containing the existing code and another "slapdash" app to show more sophisticated layouts would bridge this.

To your point, I separate my code in a similar way, with layouts and callbacks in various files. The only clean way I found to do this was to wrap each set of callbacks and layouts as functions and then import in to a dash-apps.py and assign the callables to e.g. app.layout.

@delsim
Copy link
Contributor

delsim commented Oct 30, 2018

You're free to use whatever file/directory structure you want for the dash app; the only requirement is that you cause each DjangoDash instance to be constructed, as it is the constructor that registers the app instance with the django-plotly-dash infrastructure.
This can be easily achieved by importing a file containing such an instance into a urls.py or views.py file of a Django app; this approach is used for example in the demo.

@delsim
Copy link
Contributor

delsim commented Oct 30, 2018

Its probably also worth noting that one of the original design goals was to make it as simple as replacing Dash with DjangoDash to use an existing app.

@brylie
Copy link
Contributor Author

brylie commented Oct 30, 2018

Cool, thanks. I really appreciate your timely feedback and suggestions.

I will try to figure out a project structure, based on your recommendations :-)

@eddy-ojb
Copy link
Contributor

eddy-ojb commented Jan 4, 2019

I am toying about with using mainly Dash for a new app within a project but still allowing Django and DPD to handle the project with all the benefits that come with it, such as the model engines authentication, ASGI etc.

Has anyone any opinions or words of advice on using a router to load different page layouts but without reloading an entire Dash app for another page i.e. a single page app (SPA) with different layouts via a router?

@eddy-ojb
Copy link
Contributor

I have been toying about with routing within DPD following a single page app approach with multiple pages. My method was pretty easy: follow the Dash documentation for multi-page routing but be aware of handling url routing by Django carefully in terms of the url where your app is mounted.

In terms of the project layout, I made a folder structure similar to the below:

django_project
> django_app
(usual-django_files)
> dash_app
> templates
> callbacks
> custom_components
dash_app.py
dash_router.py

There are obviously ways of condensing this depending on your project or app needs.

One of my gripes with Dash at the moment is server-side processing for all interactions, simple or complex but apart from this it can run with reasonable speed as long as the app content isn't too big.

@GibbsConsulting GibbsConsulting added the Stale Issue has aged and is now stale label Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issue has aged and is now stale
Projects
None yet
Development

No branches or pull requests

4 participants