Create a decorator to loading buttons and raise errors on Alerts

[dfguerrerom]

While developing some modules, I've been using the same pattern to display errors (try, except), and toggle loading the event buttons, so I decided to create a decorator to wrap all this process, so I'm starting this discussion to incorporate it as native sepal_ui feature, and so you @12rambau can help me to make it stronger...

This is what I have:

import functools

# Definition of decorator that is receiving two arguments
def loading(btn, alert):
    def decorator_loading(func):
        @functools.wraps(func)
        def wrapper_loading(*args, **kwargs):
            btn.loading=True
            try:
                value = func(*args, **kwargs)
            except Exception as e:
                btn.loading=False
                alert.add_msg(f'{e}', type_='error')
                raise e
            btn.loading=False
            return value
        return wrapper_loading
    return decorator_loading

Use in a class:

import ipyvuetify as v
from time import sleep
from sepal_ui import sepalwidgets as sw

class Tile(v.Card):
    
    def __init__(self, *args, **kwargs):
        
        super().__init__(*args, **kwargs)
        
        self.btn_start = v.Btn(children=['start'])
        self.alert = sw.Alert().show()
        
        # Create events
        self.btn_start.on_event('click', self._process_event)
                
        self.children = [
            self.btn_start,
            self.alert
        ]
        
        # Wrap _process function with loading decorator
        self.process = loading(self.btn_start, self.alert)(self.process)

    def _process_event(self, widget, event, data):
        self.process()
    
    def process(self):

        """This will raise and exception"""
        sleep(3)
        assert 1<0, 'This error will be displayed on the alert widget'

The errors will be displayed on the alert widgets, however, they are also displayed in the IPython interface, but not when launched by voilá, this could be a good thing for debug purposes, or we can also create a capture decorator inside the loading decorator, so we can display the error thread wherever we want.

[12rambau]

this is not the first time you surprise me with decorators and it seems super nice. I still have a lot to learn about python

• As it would be used in Tile it could live as a static method in the Tile object ? I'm not sure it's possible.
• Is it possible to add extra paramaters when you call process ? (i would say yes as it is raised in the _process_event())
• This thread unconsistency behaviour between voila, Notebook and lab is killing me....
• I think it's better to use toggle_loading as it is both disabling and loading the Btn (it prevents people from clicking multiple times)

[dfguerrerom]

Basically, the decorator will wrap a function and you could add things before and after... in this case we are adding toggle loading before and after.

• If I understand well your point, the loading function will be a global method, not only for the class.
• Yes, of course, the process function will work as any other function with any parameters, I had to create that pre-function to trigger the decorated one, because it can't decorate an event function (or at least I wasn't able to do that).

Here, we can't use the @decorator as previous line of a function because (at least in my example), the decorator is receiving self class arguments (alert and btn widget), arguments that are instantiated after the definition of the functions, so that's why are wrapping in the other way.

Yes... please take a look, we could create good things using python decorators, think about this idea ;).

[12rambau]

I was also thinking this morning, It would really be much more functionnal if we can directly apply the decorator on the function that is called by the btn.

Sometime you may want to add multiple actions in the try exept which would force us with this method to have 1 function to link the btn, 1 function for the decorator, X function to call inside the decorated function.

I'm affraid it's too much layers ;-)

I tried to drive Rémi this week to build his second module (https://github.com/lecrabe/tmf_sepal) and we need to keep in mind thats some people that will use the "sepalizer" will be scientists with very little background in Python or POO.