Thank you for your feedback, Hugo. I will make sure to send these resources to the rest of the team.

At this point, it is likely that we will provide templates where the application will choose what to load, as this is the typical approach a component library should use, so the consuming app itself can decide what and how to render there.

Regards,
Marin Bratanov
Progress Telerik

Thank you, Patrick. I must note once again that programmatic component creation is impossible in Blazor, so something like .AddContent() or .AddInstance() will be tough and will likely require foreach loops over view models. Let's see how the framework evolves, though, something might become available that will make such a task more manageable.

--Marin

Thank you for your feedback, Patrick. To bring some thoughts from the other end of this implementation and to ask some clarifying questions:

• Serializing components is impossible in blazor, the render tree is not serializable. Thus, any state saving will have to be some custom implementation, especially for the content. This is one of the trickiest parts. If you are familiar with WebForms - take a look at the complexities around  this in our RadDock - the situation is pretty similar (but you have far fewer lifecycle events in blazor and you can't create components programmatically like in WebForms).
• How would you expect adding/removing a panel (card, dock) to happen? What is the UI and UX of that action? How should the component know where to add an item and with what size and content, especially considering the declarative-first nature of Blazor?
• Even if a method is available that returns a form of state (let's say number of panels, their locations, sizes, titles), it would be possible to read it in a foreach loop. At the moment, you can do something similar in your own view-models. A similar example is available for our tab strip (see the last snippet here). Would such store-restore of the state work for you, as it would also let you define components for the content from the view model? What kind of component would you expect on top of that, considering you can add your own cards as components, and you could also style those cards with our themes right now (apart from some form of drag/resize)?
• How would you expect dragging and resizing to expose the new state? How should they re-arrange the other contents considering that we can't know the HTML layout and sizes (for example, the entire layout component should not allow other content but cards, and they should resize in some steps, or through some other constraints)?

The point in asking these questions is that there is a huge amount of undefined and non-deterministic behavior in such a component, and exposing configuration options and API for it will either limit some scenarios, or require a lot of application logic. Clarifying such expectations and preferences on how you expect to use it can help defining them.

Regards,
Marin Bratanov
Progress Telerik

To everyone, we have reopened this to gather feedback and requests. You can still review the discussion for the technical issues that prevent implementation at the moment, yet you can keep voting and commenting on what you need and what is the use case, so we can get a better picture of what you need, so we could build it.

Regards,
Marin Bratanov
Progress Telerik

Hi Andries,

To expand a bit on this, as this is a public thread.

We do have a similar component in our UI for ASP.NET AJAX suite - RadDock. It encroaches into application logic territory and with the amount of features it is expected to provide, it becomes quite difficult to use, maintain and configure. For one, it requires zones, layouts and some for of persistence, plus a way of re-generating instances from a data source, and their content. In Blazor (or, generally, Razor), the idea is that you can put all of this conditional markup and component generation in your own application code so it can directly step on the models and data you have, without an added layer of complexity.

Another major problem is that this is basically CMS-level functionality - letting your users re-arrange and save layouts/designs. It is by far not a simple task at the component level - this is why entire applications exists that perform this task. For example, in the Telerik Sitefinity CMS you can create custom modules for your end users to re-arrange and they can create dashboards like that.

These are some more of the reasons why we are reluctant to implement such a component for Blazor, it is not just the technical feasibility - it simply goes beyond the scope of components, and becomes messy. On the other hand, if we create a draggable component, it is likely that it will offer an event or a way to know where it was dropped, so it is likely that you will be able to implement similar logic yourself by storing all necessary data with your own code, logic, approach and preferences.

Regards,
Marin Bratanov
Progress Telerik

Hello Andries,

To the best of my knowledge, the Syncfusion Blazor components are wrappers over their jQuery suite, and not native components, while we are working on creating native components from the ground up.

In our tests so far dragging stuff in Blazor that has native components inside is limited, at best. While dragging with just HTML is likely possible, things will get messy when actual native components are thrown into the mix. Even if we implement a draggable component, we will have to wait for the framework to mature enough to allow it.

Moreover, our components do not aim at creating layouts, but at fitting into the application layout. Thus, I can suggest you consider Bootstrap or another similar grid layout tool for creating the layouts of the application, so you can fill them in with our components.

Regards,
Marin Bratanov
Progress Telerik

Hi Patrick,

It is out of the scope of the component suite because:

• Layouts are out of the scope of our components in general. We will not implement layouts as components or features of ours, even if we do create examples in our demos and sample apps.
• Dragging things in Blazor is next to impossible right now - not only is there no provision for it, but you have to actively fight with the framework to achieve it, and that's just dragging HTML, not components.

At this point I can't say whether docks will be implemented in Blazor at all. We don't have them in Kendo, and in WebForms where we do, they have historically been difficult to use and have been causing a lot of issues and difficulties, mostly because state persistence and re-creation is very tricky. This is why such tooling is usually in the realm of full-blown CMS solutions and not component suites.

Regards,
Marin Bratanov
Progress Telerik

Hi James,

We produce UI components and not a CMS or layout generator. Perhaps a drawer-like side-nav would be implemented at some point as per your other request, and perhaps a toolbar, but a drag-and-drop layout generator is out of our product scope.

Regards,
Marin Bratanov
Progress Telerik

Hi James,

Layouts are something highly specific to the concrete app and are not very reusable. We focus on reusable components instead. Layouts are usually created through other tools (such as bootstrap) for the particular needs of the site.

What I can suggest is that you download our demos and see how we made the layout there, or download the dashboard app we have to see if you like its layout so you can reuse it: https://github.com/telerik/blazor-dashboard.

Regards,
Marin Bratanov
Progress Telerik