vuetify template

[12rambau]

@ingdanielguerrero I just want to verify that you have access to that. And then start a converstation about ipyvuetify template and there usage in the lib

I'll wait for your green light

[dfguerrerom]

Hey Pierrick, let’s discuss about that, I have access.

[12rambau]

Ok I finally managed to get some time to answer,

I dig into the vuetify templates and they are amazing. Tha ability to intrduce js directly into the template make it super easy to use directly templates from the vuetify website.

So I would say that for specific usages as a last resort solution it's awesome
I used it super recently to create a copy to clipboard link :

class MyCopyPaste(vy.VuetifyTemplate):
    template = traitlets.Unicode('''
    
    <template>
        <v-col>
            <v-btn icon @click="copyToClipboard()">
                <v-icon>mdi-content-copy</v-icon>
            </v-btn>
            <textarea v-model="my_text" ref="text" style="display: none" />
        </v-col>    
    </template>
    
    <script>
        modules.export = {
            methods: {
                copyToClipboard() {
                    const txt = this.$refs.text
                    txt.style.display = 'block';
                    txt.select();
                    document.execCommand('copy');
                    txt.style.display = 'none';
                }
            }
        }
    </script>
    ''').tag(sync=True)
    
    my_text = traitlets.Unicode('').tag(sync=True)
    
mcp = MyCopyPaste()
mcp.my_text = 'Hello\nWorld'
mcp

BUT as you see in this very small example it's a complete freezed element that cannot be changed in any ways and I don't think it's a good idea to introduced freezed things in the lib. I was thinking that the element that we provide in the lib are starting points that can still be customized by the end developer.

I already have 2 examples in mind :

In the import aoi module I change the title of the aoi_tile because it was adapted to the module

aoi_tile= aoi.TileAoi(aoi_io, methods = ['Draw a shape', 'Upload file', 'Use points file'])
aoi_tile.set_title('Convert to Google Earth Engine asset')

or in the pysmm module my last PR is to remove the shade from the same tile to better integrate in the menu you created :

aoi_tile = tiles.aoi_tile(aoi_io, remove_method=['Country boundaries', 'Draw a shape', 'Upload file'])
aoi_tile.children[0].elevation = 0

it would be impossible with a vuetifytemplate.
I would prefer to explain that it exist (once they publish the final documentation of sepal, I don't to work on doc twice) and let people use it in their project and only provide modular stuff in the lib.

In short I need to be convinced 😄

[dfguerrerom]

Yes, I agree with you in terms of the less widget personalization, I'm not intended to replace or remove our existing widgets but just create new ones where there are some limitations in the functionalities, my example is the current ipyvuetify bug with the slots, that suddenly disappear, that's I wanted to create the DatePicker based on template...

According with this, I'm not sure what do you refer when you said this sentence:

...small example it's a complete freezed element that cannot be changed in anyways...

Actually, the templates can be customized in all the sense, but of course, it will require more work, but as I said, we could include in the library this option for specific places.

[12rambau]

Ok I'll better explain this very point. The lib provide flexible objects that still embed kwargs to add options from the ipyvuetify lib.
As objects I can still use the __dict__ keyword to see what's inside and change it as an end user.

If we go for templating, the end developer, so not us that have access to the sepal_ui lib but the one that are just using it (I myself supervise 2 at the moment, and I hope it will increase), they will not have the possiblity to change these kwargsanymore. On our side I doubt that we want to create templates that have traitletseverywhere. So that's a first loss.

second loss, as an end user you also loose the ability to see the used options using __dict__ as it's now just a template. So you're not able to customize it anymore.

It looks like a pandora box to me. We will start doing our custom templating and in the end I will only use mine and you will only use yours because we will customize them to our needs.

---

Nevertheless I strongly agree that some bugs exists in the ipyvuetify object based implementation.
What I would suggest as a dev plan :

• we only add reusable widgets (the specific one stay in the module they have been build for)
• I f a bug occurs, we correct it by wiring a template version of the widget and open an issue in ipyvuetify
• once the bug is fixed we rewire it in a object based framework

It could easily be applied to the DatePicker widget and its slotbug

[dfguerrerom]

I totally agree with you. I know the limitations of templates, and my aim is not to replace the current ones that are working well, just to have some alternative and specific widgets-templates to fix the ipyvuetify bugs (at this moment I'm only thinking on DatePicker).