I was wondering if there was a way to add subscriptions to components or if that was in the pipeline.
I want to create reusable views that have their own states, messages, etc. Component seems to be the solution but I might need subscriptions because of sockets and real-time event handling
The use of components for organizing an application is discouraged!
Instead, keep your state centralized in one place and plumb all the data manually.
Hey @hecrj .
Thanks for the reply. I do see why components are discouraged in iced/elm in general. However, I think I have the odd case where I need a reusable UI that needs a separate state/update from the main UI:
My app is basically composed of the main UI itself and a library of views. The idea is to keep the codebases separate so that I don’t have to update the main UI code when I update the library.
The Elm Architecture composes very well.
What are you exactly struggling with?
Sorry for the delayed response.
What is odd in my scenario is that I want to have two code bases: A library of iced views with each view acting as its own mini app and a main codebase that hosts those views as a pane in a pane_grid. The reason for the separation is that I want to have a modular design where the pane developers only have to write their pane code and not have to worry about the host code. You can almost think of it like people developing plugins for VSCode.
So while I could use Elm composition, wouldn’t that require me to add new messages and update functionality to the host code every time someone makes a pane?
Iced components seemed to be a good fit in my scenario since each component basically is a mini iced-app. However, I understand from your previous comments and many things I’ve read about Iced that dealing with components is highly discouraged.
Not necessarily. You could have a single View and Message type in your library crate with hidden implementation details and simply write the plumbing in your main crate once.