Sidebar tray #507
@@ -1,11 +1,11 @@
|
||||
|
|
||||
import { ReactFragment, ReactNode, useEffect, useReducer, useState } from 'react'
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
import React, { ReactNode } from 'react'
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
import { SvgNames } from 'src/components/Svg/Svg'
|
||||
|
||||
interface SidebarConfigType {
|
||||
name: string,
|
||||
icon: SvgNames,
|
||||
disabled: boolean,
|
||||
panel: ReactFragment | null,
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
panel: ReactNode | null,
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
}
|
||||
|
||||
export const sidebarTopConfig : SidebarConfigType[] = [
|
||||
@@ -67,14 +67,7 @@ export const sidebarBottomConfig : SidebarConfigType[] = [
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
Love this thank you I will take a look Love this thank you I will take a look
|
||||
name: 'Settings',
|
||||
icon: 'gear',
|
||||
disabled: false,
|
||||
panel: <article className="">
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
{ settingsConfig.map(item => (
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
<details key={'settings-tray-'+item.name}>
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
<summary className="px-2 py-1 bg-ch-pink-800 bg-opacity-20 my-px">{ item.title }</summary>
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
{ item.content }
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
</details>
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
))}
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
</article>,
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
panel: <SettingsMenu />,
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
},
|
||||
]
|
||||
|
||||
@@ -84,12 +77,11 @@ export const sidebarCombinedConfig = [
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
Love this thank you I will take a look Love this thank you I will take a look
|
||||
]
|
||||
|
||||
function SettingsMenu() {
|
||||
console.log('hello?', settingsConfig)
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
return (
|
||||
<article className="px-2 py-4">
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
<article className="">
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
{ settingsConfig.map(item => (
|
||||
<details key={'settings-tray-'+item.name}>
|
||||
<summary>{ item.title }</summary>
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
<summary className="px-2 py-2 bg-ch-pink-800 bg-opacity-10 my-px">{ item.title }</summary>
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
|
||||
{ item.content }
|
||||
</details>
|
||||
))}
|
||||
|
||||
|
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this. I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
> a button anywhere on the page can open the tray
indicates to me this should be handled through app state
Love this thank you I will take a look Love this thank you I will take a look
Love this thank you I will take a look Love this thank you I will take a look
|
||||
@@ -32,7 +32,7 @@
|
||||
|
||||
@layer components {
|
||||
.tabToggle {
|
||||
@apply text-ch-gray-300 p-3 mb-3 flex justify-center;
|
||||
@apply text-ch-gray-300 p-3 mb-1 flex justify-center;
|
||||
}
|
||||
.tabToggle.active {
|
||||
@apply bg-ch-pink-800 text-ch-pink-300 bg-opacity-30;
|
||||
|
||||
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state
Love this thank you I will take a look
Love this thank you I will take a look