jhsmit / awesome-solara

Awesome solara showcase and examples

awesome-solara

Awesome solara playground

awesome-solara's Issues

asyncio.run() cannot be called from a running event loop on reading file

Depending on the implementation of reading out files from either awesome_solara.components.<file_input / file_input_handler>.FileInput I get a RuntimeError.

Steps to reproduce:
solara run examples/single_fileinput.py

Upload a file from the example_data directory, type something in the text field and press the 'add' button.

This gives the errors below. I can understand that calling asyncio.run() in the wrong place can give an error, but I don't see exactly why the implementation of NewItemAsyncIORunTimeError does give the error while everything works fine is I swap it out with NewItem (lines 177-178).

I guess its because when I use NewItem, the on_file callback gets called in a hooks.use_thread context?

In the console:

 RuntimeWarning: coroutine 'ClientSideFile.readinto.<locals>.read_all' was never awaited
  self._reader = parsers.TextReader(src, **kwds)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

In the browser:

Traceback (most recent call last):
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\reacton\ipyvue.py", line 23, in handler
    callback_ref.current(*args)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\reacton\ipyvuetify.py", line 22, in drop_arguments
    on_click()
  File "C:\Users\jhsmi\pp\awesome-solara\examples\single_fileinput_concat.py", line 141, in on_click
    df = pd.read_csv(file_info[0]["file_obj"])
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\util\_decorators.py", line 211, in wrapper
    return func(*args, **kwargs)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\util\_decorators.py", line 331, in wrapper
    return func(*args, **kwargs)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\io\parsers\readers.py", line 950, in read_csv
    return _read(filepath_or_buffer, kwds)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\io\parsers\readers.py", line 605, in _read
    parser = TextFileReader(filepath_or_buffer, **kwds)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\io\parsers\readers.py", line 1442, in __init__
    self._engine = self._make_engine(f, self.engine)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\io\parsers\readers.py", line 1753, in _make_engine
    return mapping[engine](f, **self.options)
  File "C:\Users\jhsmi\Miniconda3\envs\py39_solara\lib\site-packages\pandas\io\parsers\c_parser_wrapper.py", line 79, in __init__
    self._reader = parsers.TextReader(src, **kwds)
  File "pandas\_libs\parsers.pyx", line 547, in pandas._libs.parsers.TextReader.__cinit__
  File "pandas\_libs\parsers.pyx", line 636, in pandas._libs.parsers.TextReader._get_header
  File "pandas\_libs\parsers.pyx", line 852, in pandas._libs.parsers.TextReader._tokenize_rows
  File "pandas\_libs\parsers.pyx", line 1965, in pandas._libs.parsers.raise_parser_error
RuntimeError: asyncio.run() cannot be called from a running event loop

toestand Reactive event

I'm trying to use solara.lab.Reactive to trigger the .cancel() method on the file input widget.

My current attempt is here (awesome_solara.compoments.fileinput_handler) but this does not work because I cannot access the widget like this.

I somehow need to use use_effect but I'm not sure how to subscribe to the Reactive toestand I pass in such a context.

`FileInput` implementations

I have implemented two versions of ipyvuetify.extra.FileInput. They both more or less work and I'm looking for feedback on the implementation.

They are in awesome_solara.components.<file_input / file_input_handler>. The file_input.py implementation is copy/paste of the solara FileDrop.
The implementation from _handler attaches a handler as shown in the medium post on reactive

I understand why we need to use use_effect, but are there pro/cons to each approach?
The _handler returns a cleanup function, the other does not, is that here not required since we do not attach any handler to the widget?