Component with service provider

[marko-js-archive]

Component with service provider

[patrick-steele-idem]

My thinking is that only the top-level UI component should actually make service calls to get the needed data. Nested UI components should be dumb UI components that just render HTML based on the data given to them. There might be edge cases where it makes sense for a nested UI component to make a service call, but that should be rare. What do you think?

[maberer]

Thanks for the answer. The issue here is not so much about where to fetch the data (although very important) but rather if a component that has a dependency to a service provider, how a user of such a distributed component ("A UI component should be installable via npm") knows about that.... The question is, if this will then be communicated solely by documentation or if it will be declared somewhere... (lets say the component is flexible and allows to have a custom service provider implementation...)

Now about the "where" to fetch the data (important to put this here too):

I generally agree with fetching data as high as possible. But lets get concrete with the following example.

Lets say we have a <app-city-container/> widget as our top-most component that manages an associative part ("route") of the application. Now, this component uses a service to fetch the names of cities (based on certain filter criteria like population > 1 Mio.). For fetching the list of cities, the <app-city-container/> component is the correct place to fetch the cities - I think we all agree on that.

Now, the <app-city-container/> component renders the cities as a list, whereby each city is rendered by a <app-city/> component. Due to the application requirements, there is a way to expand each of the <app-city/> components by clicking a button (rendered within this component). Clicking the button triggers a service-call "getCityData(zipCode)" that loads additional data for a city with the given ZIP code...

Now, one can argue where to fetch the additional city data.

1. method: Sluicing the button click to the top-most <app-city-container/> component and fetch the data there. When the data arrives, lookup the city with the ZIP code in the list (array) of cities and manipulate the object by changing an array item.
2. method: Fetch the data directly in the <app-city/> component --> change the state of the component when the data arrives.

Method 1 seems a bit harder to implement, requires an additional lookup of the array item when the data arrives, requires to have the complete data set available as "state" (may take quite a bit of memory), and strongly depends on the performance of the library implementation (no that big issue with Marko but requires to rebuild the array or some setDirty() tricks anyway)...

Method 2 fetches the data where it is rendered - pretty straight-forward. The implementation seems easier, and there is no need to hold the complete app-state in memory in order to work...
Now the crux: In strict flux (react) terms, data is always best fetched at the top (we somehow all agree on that - right).... on the other hand I feel that the react "relay" way combines both approaches somehow (each component defines its data dependencies) though it might not be that obvious to the user...

I think we all agree, that if the part that handles the click event would be implemented as its own marko widget <app-button-city-data/> it would be wrong to fetch the data there. It is obvious, that the click event needs to be communicated at least up to the <app-city/> component because this is the top-most component that makes sense... going even further depends on whether to use method 1 or 2.

So at the end of the day it is about the question, what makes more sense and where does the data belong to.... Speaking in terms like this, method 2 is the best place to fetch the data because this is the component, where the specific city data belongs to....

Instead, going all the way up to the <app-city-container/> component, might be better in terms of "data should only be entered at the top" but it has its own problems as described by method 2... (specific city data does not really belong there...?)...

Please add your thoughts.

[patrick-steele-idem]

Great thoughts and questions, @tindli. I was going to respond, but I think it's best if we build a simple sample app based on what you described to get a feel for the different options. That way, we can iterate on the code and decide what feels "right". I'm currently working on the TodoMVC app for Marko Widgets (also experimenting with different architectures on that project). After I finish the first attempt at the TodoMVC app we should continue this conversation. In the meantime, if you want to put together a sample app for what you described here I think that would be very helpful.

[maberer]

Thanks for your feedback.

I do agree that we should discuss this concepts based on code...

For a very quick review, I have updated my very basic list example app (https://github.com/tindli/marko-widget-list) to demonstrate the use of a service provider on a component.

This should demonstrate method 2 from above "Fetch the data directly in the component --> change the state of the component when the data arrives." whereby is for this example.

There is a "Show details..." on every rendered line, that utilizes a very basic service provider when clicked. It fetches city data and re-renders the view.

The example is very sparse... and with very little context...

Please add your thoughts about the use of a service provider as shown in the example.

Let me clarify the very special situation in this demo. I feel that for this example (when rendering
components into a preserved element) this is the only way to add the service provider for
the city details. We can say, that, because the items are rendered within a preserve element,
they form their own "top-level-component" within the hierarchy of components.... because
they are kinda isolated from the other parts of the hierarchy... Thinking this way, the demo here is not that different as fetching data in a top-level component like one would do when no preserved elements are used....

Anyway: please review the example and give some feedback based on the shown example.

[maberer]

I think we discussed this point in a gitter session... I am happy with it....

If there is interest in this topic, I can crawl the gitter history and find some
bits from the past.... otherwise I will close the issue.