Tooltips in copilot

[SanderGi]

Task: https://app.asana.com/0/1203067047205953/1206050253347928

Q/A checklist

• If you add new dependencies, did you update the lock file?

poetry lock --no-update

• Run tests

ulimit -n unlimited && ./scripts/run-tests.sh

• Do a self code review of the changes - Read the diff at least twice.
• Carefully think about the stuff that might break because of this change - this sounds obvious but it's easy to forget to do "Go to references" on each function you're changing and see if it's used in a way you didn't expect.
• The relevant pages still run when you press submit
• The API for those pages still work (API tab)
• The public API interface doesn't change if you didn't want it to (check API tab > docs page)
• Do your UI changes (if applicable) look acceptable on mobile?
• Ensure you have not regressed the import time unless you have a good reason to do so.
  You can visualize this using tuna:

python3 -X importtime -c 'import server' 2> out.log && tuna out.log

To measure import time for a specific library:

$ time python -c 'import pandas'

________________________________________________________
Executed in    1.15 secs    fish           external
   usr time    2.22 secs   86.00 micros    2.22 secs
   sys time    0.72 secs  613.00 micros    0.72 secs

To reduce import times, import libraries that take a long time inside the functions that use them instead of at the top of the file:

def my_function():
    import pandas as pd
    ...

[devxpy]

My take is that we should standardize this and make it a kwarg on every component, i.e. st.text_area(..., tooltip="...") and handle the rendering in react

[SanderGi]

My take is that we should standardize this and make it a kwarg on every component, i.e. st.text_area(..., tooltip="...") and handle the rendering in react

Maybe, but this would be less flexible, e.g., if we need multiple tooltips in a label next to two different words which is a fairly normal use case for tooltips then the html approach can do it but the kwargs can't. Thoughts on how we could make the kwargs approach more flexible?

Another downside to the kwargs approach is that we have to add it to every component. The html approach will work anywhere, including in the middle of text paragraphs, markup, and other html we write. Maybe we keep it like this but move the styling to a css class if the length of html that we are sending from the server is a problem?

[devxpy]

I'm trying to go with standard ways to write UI libraries here. E.g. streamlit also has this help param https://docs.streamlit.io/develop/api-reference/widgets/st.checkbox

One reason I can imagine is that having the tooltip as HTML embedded in the title text makes it very hard for anish and iccha to change how it renders.

As far as the kwargs go, you can choose not to put the explicit param right now, and just accept it on the other end of gooey-ui as **props (which we do have on most components) - (But for a great python typing experience we do want to have that static param)

[anish-work]

NEW PR - #443
Closing this!