Change Details

Linear issue: https://linear.app/comm/issue/ENG-1881/community-navigation-drawer-on-native Add drawer item implementations. There are two types of drawer items - [community] and [a thread in a community]. They behave almost the same, but there is a difference when their expand buttons are toggled: only one community can be open, so opening a community sometimes has to trigger closing another. On the other hand multiple level 1 and level 2 threads can be open at once. The information about which community is open is thus held by a parent component, and a community is passed an `expanded` flag and a `setExpanded` function allowing it to change its parents state. On the other hand each thread keeps the information about being opened or not in their own state. Why?: They could be passed that information from a parent component, just like community, but then each community (and level 1 chat) would have to keep an array of these states for all its children. The `renderItem` method would then have to be dependent on this array, so if any child changed it's 'open' state, the array would change, and in result all children would rerender. This is why I created `CommunityDrawerItemCommunity` and `CommunityDrawerItemChat` components - to handle openinng and closing elements according to the specification and avoid performace issues. The `CommunityDrawerItemChat` is not in it's own file, because then I was recieving warnings (with stack traces) about a require cycle between files, since `CommunityDrawerItemChat` renders `CommunityDrawerItem`, and `CommunityDrawerItem` has children that are `CommunityDrawerItemChat`s. I'm not sure if I should put it in a separete file despite that. It seems like a bad idea, but having two components in one flie like this seems unsanitary.

Linear issue: https://linear.app/comm/issue/ENG-1881/community-navigation-drawer-on-native Add drawer item implementations. There are two types of drawer items - [community] and [a thread in a community]. They behave almost the same, but there is a difference when their expand buttons are toggled: only one community can be open, so opening a community sometimes has to trigger closing another. On the other hand multiple level 1 and level 2 threads can be open at once. The information about which community is open is thus held by a parent component, and a community is passed an `expanded` flag and a `setExpanded` function allowing it to change its parents state. On the other hand each thread keeps the information about being opened or not in their own state. Why?: They could be passed that information from a parent component, just like community, but then each community (and level 1 chat) would have to keep an array of these states for all its children. The `renderItem` method would then have to be dependent on this array, so if any child changed its 'open' state, the array would change, and in result all children would rerender. This is why I created `CommunityDrawerItemCommunity` and `CommunityDrawerItemChat` components - to handle opening and closing elements according to the specification and avoid performance issues. The `CommunityDrawerItemChat` is not in it's own file, because then I was receiving warnings (with stack traces) about a require cycle between files, since `CommunityDrawerItemChat` renders `CommunityDrawerItem`, and `CommunityDrawerItem` has children that are `CommunityDrawerItemChat`s. I'm not sure if I should put it in a separate file despite that. It seems like a bad idea, but having two components in one file like this seems unsanitary.

Linear issue: https://linear.app/comm/issue/ENG-1881/community-navigation-drawer-on-native Add drawer item implementations. There are two types of drawer items - [community] and [a thread in a community]. They behave almost the same, but there is a difference when their expand buttons are toggled: only one community can be open, so opening a community sometimes has to trigger closing another. On the other hand multiple level 1 and level 2 threads can be open at once. The information about which community is open is thus held by a parent component, and a community is passed an `expanded` flag and a `setExpanded` function allowing it to change its parents state. On the other hand each thread keeps the information about being opened or not in their own state. Why?: They could be passed that information from a parent component, just like community, but then each community (and level 1 chat) would have to keep an array of these states for all its children. The `renderItem` method would then have to be dependent on this array, so if any child changed it's 'open' state, the array would change, and in result all children would rerender. This is why I created `CommunityDrawerItemCommunity` and `CommunityDrawerItemChat` components - to handle openinng and closing elements according to the specification and avoid performance issues. The `CommunityDrawerItemChat` is not in it's own file, because then I was reciereceiving warnings (with stack traces) about a require cycle between files, since `CommunityDrawerItemChat` renders `CommunityDrawerItem`, and `CommunityDrawerItem` has children that are `CommunityDrawerItemChat`s. I'm not sure if I should put it in a separeate file despite that. It seems like a bad idea, but having two components in one fliefile like this seems unsanitary.