Complex apps - Which API? Which Layout?

Hi !

In my quest to understand and use panel, I’m looking for the best strategy to develop a complex app. The ultimate goal being to reduce the friction while developing the app and trying to avoid making early mistakes that’d require a lot of refactoring.

By complex, I mean that the app would have:

  1. Lots of internal dependencies, i.e. parameters depending upon each others, plots depending on parameters, etc.
  2. A complex layout with lots of widgets, plots and panes, tabs, etc.

It’d probably be necessary to define more clearly what complex means in that context but these two conditions seem sufficient to start a discussion.

As for 1., the API doc page describes the 4 APIs available in panel. While it’s obvious that the interact functions are better suited for simple cases, the other APIs, namely reactive functions, parameterized classes and callbacks, could be used for more elaborated cases. As they can offer better code structure and more fine-grained control, parameterized classes and callbacks seem to be best suited APIs.

Yet, I wonder if there a more appropriate combination? If it is fine to add callbacks (.watch) on top of reactive param methods (@param.depends).? How about Javascript callback links?

I started to think about this topic after reading this Pull Request discussion where @philippjfr wrote that:

The comparison with .watch is easy because reactive patterns are almost always preferable to callback hell.

:wink:

As for 2., a lot of the examples in the gallery make use of panel.Column and panel.Row. With those two only, it’s possible to build complex layouts with tons of widgets, plots and other kind of panes. But is that a good thing to do? What kind of problem one can encounter when doing so ? I’m thinking about debugging the UI, how responsive it’s gonna be, performance, etc.

Having 4 different APIs and many Layout objects, there is for sure not only one way to build a complex app with panel. On the hand, this flexibility is great and a sort of superpower, on the other hand, it just makes it a little more difficult to reason about the structure of your app.

That would be awesome if some of you could share the code of your complex apps :slight_smile:.

I try to share my way of building Panel apps as I learn and develop at awesome-panel.org. The site it self is a single page app with multiple sub apps. I have plans to change it to a multi page app though or use the upcoming Location widget to be able to get deep links into the application.

The issues I’ve found during development of awesome-panel.org are listed under issues. The list needs updating though as some of the issues have been solved since then.

There is also a link to the code for each example in the gallery. You can also find the code on github https://github.com/MarcSkovMadsen/awesome-panel/tree/master/src/pages/gallery

I’ve started a list of tips and tricks for creating performant panel apps here https://awesome-panel.readthedocs.io/en/latest/performance.html

I know that @philippjfr has plans to write something about this one day.

2 Likes

And @maximlt

I would recommend going for the param.Parameterized api and then sprinklin in a few .watch if needed. I think that works great.

And then I would decompose my app into smaller components that are easier to develop, test and maintain. They might also be reused for other use cases.