Nativescript-ui-feedback: Discussion: SideDrawer root/nested mode

Created on 7 Nov 2018  路  5Comments  路  Source: ProgressNS/nativescript-ui-feedback

Hi guys,

We start this thread to collect some feedback on how the NativeScript SideDrawer is used in your apps and what are the most used features, or the most needed ones (in case they are missing). As many of you know, in terms of layout, the SideDrawer can be used in 2 ways:

  • as a root component - when its declaration is at the root of the app and all other app components are its children - in this mode the SideDrawer is the most "efficient", i.e. a single instance in the app, created once, does not recreate on navigation, thus not using additional memory/resources. Also, being at the root, it respects the "safe" areas in the latest iOS devices (when used with NativeScript v.5+).
  • as a nested component - like any other UI component, you need to create it per app screen. Also, on navigating back and forth the SideDrawer instances are recreated, i.e. additional work is done. In this mode multiple SideDrawer components can be shown on a single page.

For sure, we know there are downsides in any of the modes, but we want to hear from you.

  1. In what mode do you use the SideDrawer in most of the times? Root/Nested
  2. What issues do you have with either of the two?
  3. (If using nested) Whats stops you to migrate to root drawer?
  4. What do you want to see in the future in either of the root or nested modes?

So, answering to any/all of these questions will help all of us better understand what we should do to improve the plugin. Feel free to add whatever other comments you have related to root/nested modes or share screens/code of your use cases.

sidedrawer

Most helpful comment

1) Root, it's too cumbersome to put it in every view
3) Just PITA refactoring, well worth it though

Root just makes logical sense... love it vs nested

All 5 comments

1) Root, it's too cumbersome to put it in every view
3) Just PITA refactoring, well worth it though

Root just makes logical sense... love it vs nested

Generally use it as root, but need to toggle gesturesEnabled to be able to disable the drawer on Login pages for example.

In my most recent project I had to have 2 drawers and a bottom sheet. I figured out a way to allow for this by dynamically changing the position of the drawer, but ran into performance issues. In the end I had to roll my own drawer implementation (using layouts and gestures) that supported 4 sides (only used 3: left, right and bottom).

We use it both ways.

  • Root is used as a typical hamburger navigation menu on home page and some other startPoint page such as user's me page.
    screen shot 2018-11-09 at 15 48 52
  • Nested is used as let's say a filter menu or some detailed info window.
    screen shot 2018-11-09 at 15 49 09

screen shot 2018-11-09 at 15 49 49

Personally I think there should be 2 ways to implement it.

  • For the root way it make sense (at least for angular user) to bring the Sidedrawer to some higher level if it's actual shared. However, it will be a bit pain to manipulate the single Sidedrawer instance with different UI if it's not shared.
  • For the nested way it's the expected way to implement for those Sidedrawer that only lived in 1 page. Also imagine a page with multiple sidedrawer (one on the side, one on the bottom).

For now, I'm pretty happy with the current Sidedrawer. Vote for keeping both.

I used it on child of my root and share with the child ( page-outer-outlet ). But I have the problem to call sideDrawer.showDrawer() function. so i do some tricky to inject a component that has side drawer to the childs so i can use the function sideDrawer.showDrawer(). I hope you can do something about the problem I had.

@s-triar Could you please log a separate issue for your question.

Was this page helpful?
0 / 5 - 0 ratings