State Managment

[austbot]

Feature/Architecture Proposal:

I propose instead of basic Angular we implement a state management pattern. Using NGRX or NGXS, we can create highly resusable and decoupled layers to the application that increase developer happiness and make complex event based logic additions easier.

• Example: deleting a service or replica set. The operation takes time. And in the current dashboard and angular Migration branch there is no feedback or status of current operations. Using state management would make it easy (with a tried and true pattern) to create a central list of current operations, without tightly coupling every resource that can create an operation to every other resource.

• Example: real-time view of scheduling operations. Using this pattern we can have a process pulling or a socket open to a sever providing all of the current operations of the API servers in an efficient way. Without this pattern, opening up a socket would be at a component initiated level. Which would result in many sockets for specific resources and the need to open and close them as the user moves about the ui. Using a state management system, a background process can feed data into a application global store that then can be 'selected' from by components or services. This means each 'view' of the application eg a service can subscribe to th cloud events happening on that resouce without opening up another socket to the server and without having to manage the connection or cleanup.

I hope the examples make a compelling case. It's possible to make applications without state management. State management increases the initial complexity and is not advised on very simple apps. But for something like this I recommend we use it. State management is currently among the best practices of client side apps these days and for good reason.

I am willing to spear head the initiative too. Thoughts?

[jeefy]

I like this idea in principle. There's value in seeing past and pending operations, including debugging if there's a backlog. My concern is complexity. If the goal is to keep the Dashboard as lightweight as possible, additional layers goes against design.

Overall, I like the idea.

[mgred]

Like this idea! I got experience with redux and especially ngrx with angular and it's a great tool and I think a good fit for apps like the dashboard.

My concern is complexity. If the goal is to keep the Dashboard as lightweight as possible, additional layers goes against design.

In deed, state managemant comes with a cost and this means a few bits of complexity in design and development, but from my experience will lead to less complex components.

Also, libraries like ngrx enforce reactive programming which is another good practive for client side apps these days, in my opinion.

[floreks]

This is actually a great idea. I thought about that when we first started to rewrite everything, however, we've had very limited resources and time to do the migration and I didn't even mention it. Now we have more and more active contributors and this might be a chance to introduce such a mechanism. We need someone to implement a core for this so we can then refactor main components one by one. Is anyone up for this?

[jeefy]

I'd be interested in taking a crack at it.

However if someone else is interested and has significantly more time I'd opt for them. This would be something I chunk away at when there's nothing pressing. :)

[jeefy]

/kind feature

[jeefy]

/lifecycle frozen

[mgred]

I'm also very interested in joining this project.

[halcyondude]

I'm interested in joining this effort in some capacity, but I'm not sure how/where to start, and still learning about how the dashboard project is structured.

Has there been any movement on this idea? IMHO ngrx could be a great fit here.

[maciaszczykm]

@halcyondude Hi, nice to hear! Can you perhaps spend some time and prepare some PoC? Like @floreks said before, we need core components for this and then we can refactor the whole app step by step. Think that is very important here: it has to be done on the ng-migration branch, where we are finishing migration to the newest Angular (well almost... I will update it to 7 soon).

We can discuss on Slack how to move ahead, if you need any tips, have questions etc. just ping me and I will try to help.

[maciaszczykm]

Any updates or people that are still willing to put some effort to this?

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

[maciaszczykm]

Another big change a.k.a. migration is not the best idea for the project at the moment. We will track live updates feature from https://github.com/kubernetes/dashboard/issues/2541. We can also decide here about the architecture.