Are nested Consumers endorsed?

[jacob-emery]

I would like to optimize my code when possible.

My "bad" code (a bit simplified):

class Someclass extends ConsumerWidget {
Widget build(BuildContext context, WidgetRef ref) {
    final p1 = ref.watch(provider1);
    final p2 = ref.watch(provider2);
    final p3 = ref.watch(provider3);
    return BottomNavigationBar(
        type: BottomNavigationBarType.fixed,
        backgroundColor: p1.bottomNavigationBarBackground,
        ...
        items: [
            BottomNavigationBarItem(
                icon(Badge(child:SvgPicture.asset('...', color: p1.bottomNavigationBarBadge)), showBadge: p2.showBadge, elevation:..., position:..., ...),
                label: 'l1',
            ),
            BottomNavigationBarItem(
                icon(Badge(child:SvgPicture.asset('...', color: p1.bottomNavigationBarBadge)), showBadge: p3.showBadge, elevation:..., position:..., ...),
                label: 'l1',
            ),
            ... // other baritems that don't need to read p2 or p3
        ]
    }
}
}

I would like that, whenever the state of p2 or p3 changes, only the badge where p2 or p3 is being watched gets updated (maybe this case with svg pictures is a bit weird, because Badge has a child widget field that still needs to watch p1).

In general, is it safe to use nested consumers? The outer one contains final p1 = ref.watch(provider1); inside its build, while the first nested Consumer wraps the first instance of BottomNavigationBarItem instance and watches p2 there, and the other consumer wraps the second BottomNavigationBarItem instance and watches p3 there?

Code sample:

class Someclass extends ConsumerWidget {
Widget build(BuildContext context, WidgetRef ref) {
    final p1 = ref.watch(provider1);
    return BottomNavigationBar(
        type: BottomNavigationBarType.fixed,
        backgroundColor: p1.bottomNavigationBarBackground,
        ...
        items: [
            Consumer(builder(...) {final p2 = ref.watch(provider2); return BottomNavigationBarItem(
                icon(Badge(child:SvgPicture.asset('...', color: p1.bottomNavigationBarBadge)), showBadge: p2.showBadge, elevation:..., position:..., ...),
                label: 'l1',
            );}),
            Consumer(builder(...) {final p3 = ref.watch(provider3); return BottomNavigationBarItem(
                icon(Badge(child:SvgPicture.asset('...', color: p1.bottomNavigationBarBadge)), showBadge: p3.showBadge, elevation:..., position:..., ...),
                label: 'l1',
            );}),
            ... // other baritems that don't need to read p2 or p3
        ]
    }
}
}

Or is there a cleaner way to achieve this? Maybe using HooksWidgets?

[jacob-emery]

Actually, in my case p1, p2 and p3 should all watch some global state, therefore I am a bit unsure of my HookWidget suggestion.

[rrousselGit]

It's fine.

Although I'd personally prefer writing slightly more code and extracting every Consumer(...) into a custom extends ConsumerWidget class

I like to split big widgets early, and it achieves the same effect – on top of maybe allowing const constructors if your widget only depends on providers

[jacob-emery]

Thank you for your answer! I now have another question: what advantages/guarantees do const constructors of ConsumerWidget subclasses bring?
Thank you in advance!