What about common data fetching approach for svelte components?

[Greg-Bush]

Gamarjoba!

Having launched the project locally, I became interested in why almost all interfaces are empty:
is data loading in progress was still happening either probably some error occured, or just there's empty data and nothing to display, or probably some UI components are in developing process and haven't integrated with data yet?

And after looking into the code I found out that most svelty components have the loading state handling, and the rendering of existing data. But components doesn't handle errors & empty data cases.

Respectively I am curious about 2 questions:

1. What about implementing UI component like <EmptyDataMessage />, which is absolutely analog of the <Loading /> but would let user know there's a loading happened and there's no data.
2. Am I missing something about error's handling process in the codebase? I haven't dig deeply about metadata yet, so can't know exactly about relevance of this feature, either is it implemented already in some base code or not.

As example of data handling process I see getResource function, so as for now I can suggest some react-way abstraction layer in addition to this function. I would describe it in JS in order to not spend too much time on types, it's just an example to discuss.

useResource.js:

  import { onMount } from 'svelte';
  import { writable } from 'svelte/store';
  import { getResource } from '@hcengineering/platform'
  
  function useResource(Resource, params) {
    let data = writable()
    let error = writable()
    let loading = writable()
    onMount(() => {
      loading.set(true)
      void getResource(Resource).then(async (f) => {
      try {
        const result = await f(...params)
        data.set(result)
      }
      catch(e) {
        error.set(e)
      }
      finally {
        loading.set(false)
      }
    })})
    return [data, loading, error]
  }

svelte component:

import useResource from 'useResource.js'

let [someResourceData, loading, error] = useResource(some.Path.To.Resource, params)

// ... some logic to handle error & loading state in UI
// ... some logic with data result neither it empty or not

_
Regards, Grigorii

[aplatoff]

Hi Grigorii,

Thank you! You are correct. Proper error handling infrastructure is indeed a missing part in platform version 0.6. However, addressing this issue properly would necessitate significant rework which we are not ready to undertake anytime soon. It has been postponed to version 1.0 along with many other improvements and ideas based on what we've learned in the past years.

Regarding your idea, I'm not sure I fully understand it. Could you please provide a concrete example, selecting any component from the project codebase and show a before/after example?

Thank you,
Andrey

[Greg-Bush]

Yes, I was meaning query/mutation approach like in apollo-graphql & react-query frameworks.

They have awesome features like Cache policies, Auto Refetching, Polling and Optimistic Updates

This framework already exists for svelte too:
https://tanstack.com/query/latest/docs/framework/svelte/overview

I have published draft commit here:
Greg-Bush@14a3e66

There is almost the same code rows count.

But like a profit:

1. loading state
2. error state (can be switched back to default mode, when error is going to be thrown to the code neither written to local variable)
3. refetch function
   and etc.

[aplatoff]

Dear Grigorii,

Thank you for your suggestions!

Regarding the code you're refactoring and from what I can see, the primary change for the end-user seems to be a "Loading" indication. If this is the main effect you're aiming for, I believe it can be achieved more efficiently without the need for third-party libraries. Utilizing pure Svelte mechanisms and adding minimal lines of code should suffice. Please correct me if I'm wrong.

Concerning the additional benefits you've mentioned, could you please provide us with some before-and-after examples? Such examples would significantly aid in understanding how these features could positively impact our daily operations. I find the notion of abstract benefits somewhat difficult to interpret without tangible illustrations. Demonstrating specific advantages through real-life examples would be more valuable.

Thank you,
Andrey

[Greg-Bush]

Well, 'cache policies' may be useful in order to reduce the number of requests. I was a witness of an incident ones in one big company when one front-end module was dublicating every request 8 times and that was enough to burn servers of neighbour department in company. Why department hadn't configured some cache service on the backend side - another question. But if front-end developer would use any framework with client cache and 'cache policies' this incident wouldn't be happen.



Another positive side of 'cache policies' is that end user will save traffic and would wait less time on loading. It’s kinda offline-mode.



‘Auto Refetching’ - this is about refetching some particular, active on screen, queries, when some related mutations had happend. For example user changed his date of birth (changeDateOfBirth mutation), then 'age' query should be refetched. Without this layer of abstraction implementing of such a feature would take much more code than with using this framework.


‘Optimistic Updates’ - useful for UX if you want display the result of some mutation before the server will give a result. It’s about offline mode too.





Wherever the data comes from, client side should mirror data relations in client code. This framework makes it under hood, no need in defining extra global stores and other observable-boilerplate code. I've seen several projects based on redux, effector, rx and etc. with such boilerplate code that just dublicates data-source side and surely makes it incorrectly. Those projects extremely full of bugs. They have hundrets of bugs, and it one hundrets times more then in the enterprise project with apollo-graphql for example.









The difference between using this approach or not is not only in UI, since it's about the way of data manipulating. 

But it definately have positive potential for UI and UX.

"Loading state" - actually is an "after" example. It is incremental improvement. “Before" you showed spinner every time when there was an empty data, and in this case there is an infinite spinner which is confusing users. 

Other positive impacts are incremental too and real-life examples of them will not be free.
_
Regards, Grigorii

[aplatoff]

Sounds good, we would be happy if you implement 'cache policies', 'Auto Refetching' or 'Optimistic Updates' in the platform and show us benefits of any of these techniques. Thank you! -- Andrey