Refactor sidebar

[MarvinKlein1508]

This PR reworks the implementation of the sidebar to be more easy to setup.

In addition it adds unlimited levels of navitems which makes #336 obsolete.

I'Ve updated all demos and got rid of the delegate.

In addition this implemenation renders much faster compared to the old one.

Feel free to suggets changes.

[MarvinKlein1508]

@gvreddy04 coul you take a look on this? I really need more levels of navigation in our app :)

[MarvinKlein1508]

@gvreddy04 here is a render comparison from old code and new code. Notice the slight reduction of rendertime.

render_demo.mp4

[gvreddy04]

@MarvinKlein1508 Thank you very much for the PR and for your contributions. We should not remove the DataProvider parameter. Instead, we can add support for a Data parameter like Grid.

[gvreddy04]

@MarvinKlein1508 Enabling more than two levels in the Sidebar will cause UI issues, as demonstrated by the broken feature shown below. There may be other UI scenarios that encounter problems as well. I am considering alternative options for accommodating more than two levels.

[MarvinKlein1508]

@gvreddy04 oh I haven't though about the toggled menu since I'm not using it. I will take a look on it as well and add more commits to the PR.

Can you explain what the purpose of the Delegate is? When ever I need to update the sidebar entries I can just change my collection.

[MarvinKlein1508]

@gvreddy04 can you maybe add your scenario as demo to the PR?

[MarvinKlein1508]

@gvreddy04 I've updated my PR.

I have fixed it by getting rid of the background color and using indention instead. For example:

Previous:

New:

Also works in collapsed mode.

@gvreddy04 could you tell why the DataProvider is necessary? For which use cases?

I don't see any benefit in using the DataProvider since the changes IEnumerable will be rendered on the fly automatically.

[MarvinKlein1508]

Hi @gvreddy04,

I gave this one another shot. Now I know why you'll need to use the SidebarDataProviderDelegate. This one is needed so you can do async calls within the rerender of the component.

I've added a new commit with brings back the SidebarDataProviderDelegate but otherwise is changed to support unlimited levels of navigation.

Feel free to give me feedback or suggestions :)

[MarvinKlein1508]

@gvreddy04 would be nice to have this one in the next version. Right now I use a custom copy of the component in my app in production.

[MarvinKlein1508]

Did you find some tiem to come back to this? I really need this in our apps.

[gvreddy04]

#565

[MarvinKlein1508]

@gvreddy04 I've updated this PR with the removal of the ClassBuilder

[gvreddy04]

@MarvinKlein1508 Taken care in #605.

[MarvinKlein1508]

@gvreddy04 thanks for the info. Could you tell my why you are using this Id and ParentId apporach? Why not have a List within the NavItem class itself. Would make generating it much easier. What'S the benefit of using the Id approach here?

[MarvinKlein1508]

ping @gvreddy04

[gvreddy04]

@MarvinKlein1508 Sidebar implemented with the Id and ParentId approach.

First, we want to maintain the same consistency for Sidebar2 so that people can switch without any extra code changes.

Second, some people might persist NavItem (or user privileges) in the database. This is where the implementation began.

Performance-wise, we will revisit Sidebar and Sidebar2 in the next release. You raised a concern with this approach. I'm not opposed to your feedback. I'll see about providing an option to input data in two formats. I'll create a Feedback issue; please add your proposal and its benefits.

Also, mention in your case whether you are providing dynamic or static data.

Our intention is to help developers and make them more productive with the ease of use of our components.

I always appreciate your contributions in all ways, including pull requests and answering others' questions. Thank you!

[gvreddy04]

@MarvinKlein1508 Feedback: Sidebar & Sidebar2 Components #620