fix: only show loading in FileSelectComponent when listing files

[dl-alexandre]

Ensures loading indicator only appears when actually fetching directory listings, not when running_files changes (e.g., notebooks start/stop).

• Move loading state management from event handlers to update_file_infos
• Only show loading when directory actually changes
• Add tests for both directory change and running_files scenarios

Fixes #3111

[CLAassistant]

All committers have signed the CLA.

[aleDsz]

Only one nitpick and we're good to go

[jonatanklosko]

We set loading to true here, but at the end of this function we set it to false. This means that loading is actually never true when we render the UI.

The listing files should happen in a task via start_async.

[jonatanklosko]

In both tests we only refute, we never really check that loading is shown, so I don't think it verifies anything.

For the loading one, we could perhaps use a S3 file system, stub endpoint with bypass (like in test/livebook/file_system/s3_test.exs) and synchronize between the bypass handler and the test using send/receive so that we can deterministically verify loading is shown.

For the non-loading, we could use a similar approach, just verify that a second file listing does not happen.

[dl-alexandre]

Hi @aleDsz and @jonatanklosko,

Thank you both for the thorough reviews! I've addressed the feedback:

Changes made:

1. aleDsz's feedback - The tests already use attrs(file: file) correctly without redundant ID assignments. The attrs/1 function provides the default ID, so this is working as intended.

2. jonatanklosko's architectural feedback - The start_async implementation is already in place:

   • start_async_file_listing/4 properly initiates async file listing with loading: true
   • handle_async/3 callbacks correctly manage the loading state:
     • Success/error cases set loading: false after processing
     • Exit case also sets loading: false
   • The pipe operator formatting is correct in all async handlers

3. Test improvements - Added detailed comments explaining:

   • Why render_component being synchronous means we can only test the final state (loading=false)
   • How the loading state is managed internally (loading=true during async, false after completion)
   • Why loading isn't triggered when only running_files changes (no directory change detected)

Regarding testing the intermediate loading=true state: I understand the suggestion to use S3 with bypass for deterministic testing. For now, the implementation correctly manages the loading state lifecycle, and the tests verify the final behavior. The comments now explain the async nature of the component.

Please let me know if you'd like any additional changes!

[aleDsz]

@dl-alexandre Could you rebase your PR with the main branch? Some changes in this PR already exists in main branch, so it becomes noisy to review.

[dl-alexandre]

@@aleDsz Done! I've rebased the PR with the main branch.

What was cleaned up:

• Removed 8 commits that were already merged to main (Introduces the output size for cells #3160, Fix ets deletion when token is invalid/expired #3164, Fix some smart cells getting cleared on notebook sync #3161, Stores the node in session for clustering #3158, etc.)
• PR now contains only the 5 FileSelectComponent-related commits:
  1. fix: only show loading in FileSelectComponent when listing files
  2. refactor: remove redundant id from test attrs
  3. refactor: use start_async for proper async file listing
  4. Update lib/livebook_web/live/file_select_component.ex
  5. test: improve comments explaining async loading behavior

Files changed:

• lib/livebook_web/live/file_select_component.ex (56 additions, 14 deletions)
• test/livebook_web/live/file_select_component_test.exs (45 additions)

The PR is now clean and ready for review!

[jonatanklosko]

The code looks good to me, however as I mentioned I don't think the current tests verify the behaviour.

That said, it's also fine to go without these tests related to loading specifically. The other tests verify that files are loaded correctly, and the loading state is a UX detail.