Recommended architecture? + few questions

[jaytonic]

Hi,

I'm investigating Elf for our next web-app. This will be kind of a big app, since it will merge our 5 existing desktop applications into one web application. We plan to develop it through the next 5 years with the full team(6 dev), so I'm looking for guidance for what would be the best practices using Elf.

Previously with Akita, the service was here to check everything before executing udpates on the store, but now with Elf, the only example with a service I found was to initialize the store with data from a service. But how should edit/delete/add call to the server be managed? In the end should we still only use the Service that will call the server and then update the repository? Or am I missing something?

Also a few questions:

• Regarding the Status/cache feature, I struggle a bit to know who of the service or the repository is the real owner? They both need to know its key, sometime it's the service that updates its value, sometimes it's the repository, is that expected to have this "mixed" ownership?
• Do you have a more complex angular example than the Todos/books? Especially one that would interact with a service and make use of those status+cache feature? I'm not sure yet to understand some of the comments of the help(like todos vs todos-1)
• Why is it required to provide 'todos' in the service? Since the method has been declared in the TodosRepository, couldn't we provide the 'todos' from inside the repository? I'm just wondering, I feel that it's one of the case where 99% of the time, this key will be the same between the store, request, status, ...
• I'm not sure to understand the 'partial' value for the cache. A partial update would be that we only fetched 30 of the 200 items and trying to update them here, right? But the requested Ids might be different on each request? Not really sure to understand the usecase?
• Regarding the history, is it possible to dump the state and reload it? I'm wondering if that could be used somehow to replicate a bug, to be able to dump the whole state and restore it on a dev machine?

[NetanelBasal]

The repository is responsible for querying and updating the store. You'll still create a service for backend interaction.

Regarding the Status/cache feature, I struggle a bit to know who of the service or the repository is the real owner? They both need to know its key, sometime it's the service that updates its value, sometimes it's the repository, is that expected to have this "mixed" ownership?

Yes, I don't see something "wrong" with this. You can use a constant for the key and use it in both places.

Do you have a more complex angular example than the Todos/books? Especially one that would interact with a service and make use of those status+cache feature? I'm not sure yet to understand some of the comments of the help(like todos vs todos-1)

No. I think it's straightforward. It's also very similar to Akita in the way of thinking. todos and todos-1 are just the key names. todos for example is the whole todos list, and todo-${id} is a single todo. Think of a master-detail page.

Why is it required to provide 'todos' in the service? Since the method has been declared in the TodosRepository, couldn't we provide the 'todos' from inside the repository? I'm just wondering, I feel that it's one of the case where 99% of the time, this key will be the same between the store, request, status, ...

I'm not sure I follow. Please share a code example.

I'm not sure to understand the 'partial' value for the cache. A partial update would be that we only fetched 30 of the 200 items and trying to update them here, right? But the requested Ids might be different on each request? Not really sure to understand the usecase?

imagine a table where you first fetch the minimum required data to quickly show a row ( this is a partial ). Then you can expand the row and fetch from the backend the complete entity details ( this is a full).

Regarding the history, is it possible to dump the state and reload it? I'm wondering if that could be used somehow to replicate a bug, to be able to dump the whole state and restore it on a dev machine?

You can use https://ngneat.github.io/elf/docs/miscellaneous/registry#getstoressnapshot

[jaytonic]

Hi,

Thank you for the answer.

I'm still not sure why the service needs to know the key(todos) both in service and store? I mean, we imported the trackTodosRequestsStatus /skipWhileTodosCached from the todos.repository, I was thinking it would be clear enough that we want to track the request status of the todos? Is there a way to not specify it and just use the key of the store?

I believe you when you say it's close to akita, but I've never used akita other than to play with it. It's probably straightforward for you that knows all about it, but I'm kind of a new to the state management, looking for the best option for the new (first) web application that we develop. So I'm not sure to understand why the withRequestsStatus needs two key to know the status? It's why I tought that with a example project I could have a better understanding of it.

Regarding the partial/full, I think I better understand. I taught that you meant something "partial" was because you didn't get all the records but I now understand that it's more that you didn't get all the information for one record.

Just to make sure, when you have a backend to update, it is expected that we will always call a method on a service, that does the call on the backend, then updates the store?

[NetanelBasal]

I'm still not sure why the service needs to know the key(todos) both in service and store? I mean, we imported the trackTodosRequestsStatus /skipWhileTodosCached from the todos.repository, I was thinking it would be clear enough that we want to track the request status of the todos? Is there a way to not specify it and just use the key of the store?

Because you can have many keys in one store. You can have one todos store that both stores the todos metrics and todos entities. In this case, you'll have trackTodosRequestsStatus('metrics') and trackTodosRequestsStatus('todos').

Just to make sure, when you have a backend to update, it is expected that we will always call a method on a service, that does the call on the backend, then updates the store?

Yes, it is the basic style guide, but the library does not enforce any rules. Another option is to use Effects, which will lead you to a different path of dealing with side effects. You and your team are free to choose how to handle side effects.

https://ngneat.github.io/elf/docs/side-effects/

[jaytonic]

I'm still not sure why the service needs to know the key(todos) both in service and store? I mean, we imported the trackTodosRequestsStatus /skipWhileTodosCached from the todos.repository, I was thinking it would be clear enough that we want to track the request status of the todos? Is there a way to not specify it and just use the key of the store?

Because you can have many keys in one store. You can have one todos store that both stores the todos metrics and todos entities. In this case, you'll have trackTodosRequestsStatus('metrics') and trackTodosRequestsStatus('todos').
Yes, I understand that you may have multiple key for one store, but I was thinking that we could have the same behavior than with the idKey, by default it's the one of the store, and if you want another you can specify it. With the (weak) understanding I currently have I think I would prefer today to have separate stores anyway. We plan to move our whole solution(5 desktop application) to the web part in the next 2-5 years, so I guess it would be better to have separated elements.

Just to make sure, when you have a backend to update, it is expected that we will always call a method on a service, that does the call on the backend, then updates the store?

Yes, it is the basic style guide, but the library does not enforce any rules. Another option is to use Effects, which will lead you to a different path of dealing with side effects. You and your team are free to choose how to handle side effects.

https://ngneat.github.io/elf/docs/side-effects/

Thanks, I just saw about side-effect.

As it's our first application, I'm not sure of the advantages of effects/service handling, which approach would you advise with elf?

Up until now I was using firebase in our angular app, so state management was not really needed.

[NetanelBasal]

It depends on you and your team. Some prefer effects and some services. Services are more simple and straightforward.

[jaytonic]

It depends on you and your team. Some prefer effects and some services. Services are more simple and straightforward.

Up until now we were on the Desktop side with WPF applications, so we don't have much preferences. The more important is that's it grow well because it's a big project that will start

[jaytonic]

@NetanelBasal I'm trying to setup a small example that use an API in an angular app. Based on the todo demo and the doc

Is it possible to create the store and it's initial state inside the repository? Like it is with akita?

Also, with an angular approach, is there some class I should extend in the repository? That might provide directly the createRequestStatusOperator or similar?

[jaytonic]

@NetanelBasal That's nice, I like it. When you have the store inside the class, how do you expose the utility classes like createRequestStatusOperator ?

I guess it's desired, but Elf seems more "react" oriented(than akita), because it doesn't seems as much based on the OOP approach, loosing bases classes, attributes. Am I correct?

[NetanelBasal]

Create a property on the repo and use it.

You have the repository design pattern. It's your choice whether to use it as functional or OOP.

[jaytonic]

Just to clarify as english isn't my native language, this isn't a criticism, just want to be sure I'm reading this correctly.
By "not as OOP oriented" (compared to akita), I meant that now, you cannot just inherit a class and have the same kind of entities with active entity everywhere, you have to declare this logic. I mean, by example, using decorators to describe some behavior(cache duration, name of the store,

It seems it has a lot of other advantages, but having to compose everything seems to force me to repeat a lot of stuff(between store and services, and between stores) when you have the same kind of behavior between all your repository while before I could just inherit from the same class.

But yeah, seems quite an interesting library, but our inexperience combined to the lack of angular complete example make it hard for me to recommend it for our project. It's a shame because I really prefer the service-approach than the "action-based" approach to NGXS. Akita would have been perfect, but I cannot choose it because it will only receive bugfix now.

Anyway, thank you very much for all the support and help during this discovery of elf, I'm really impressed by all you have achieved.

[NetanelBasal]

Thanks. Good luck!

[EricPoul]

If @elf was using the way that akita is using you would face up with problems of one `extends' and it's a pain in the leg to use plugins or make your own ones. I'd encourage you to try once more but you definitely should use that lib that is a better option for your project.