Sidebar tray #507
@@ -1,6 +1,7 @@
|
||||
import { useState } from 'react'
|
||||
import Svg from 'src/components/Svg/Svg'
|
||||
import { sidebarTopConfig, sidebarBottomConfig, sidebarCombinedConfig } from './sidebarConfig'
|
||||
import { useIdeContext } from 'src/helpers/hooks/useIdeContext'
|
||||
|
||||
function TabToggle({ item, className = "", active, onChange, onClick }) {
|
||||
return (
|
||||
@@ -20,29 +21,24 @@ function TabToggle({ item, className = "", active, onChange, onClick }) {
|
||||
}
|
||||
|
||||
const IdeSideBar = () => {
|
||||
const [selectedTab, setSelectedTab] = useState("")
|
||||
const [lastOpen, setLastOpen] = useState("")
|
||||
const { state, thunkDispatch } = useIdeContext()
|
||||
|
||||
function onTabClick(name) {
|
||||
return function() {
|
||||
if (selectedTab === name) {
|
||||
setLastOpen(selectedTab)
|
||||
setSelectedTab("")
|
||||
} else if (selectedTab === "" && lastOpen === name) {
|
||||
setSelectedTab(name)
|
||||
}
|
||||
thunkDispatch({type: 'settingsButtonClicked', payload: [name]})
|
||||
}
|
||||
}
|
||||
const selectedTab = React.useMemo(() => sidebarCombinedConfig.find(item => item.name === state.sideTray[0]), [state.sideTray])
|
||||
|
||||
return (
|
||||
<section className="flex h-full bg-ch-gray-900">
|
||||
<section className="flex h-full bg-ch-gray-900 border border-red-500">
|
||||
<fieldset className="h-full flex flex-col justify-between bg-ch-gray-700">
|
||||
<div>
|
||||
{ sidebarTopConfig.map((topItem, i) => (
|
||||
<TabToggle
|
||||
item={topItem}
|
||||
active={ selectedTab === topItem.name }
|
||||
onChange={ () => setSelectedTab(topItem.name) }
|
||||
active={ state.sideTray[0] === topItem.name }
|
||||
onChange={ () => onTabClick(topItem.name) }
|
||||
onClick={ onTabClick(topItem.name) }
|
||||
key={ 'tab-' + i }
|
||||
/>
|
||||
@@ -52,18 +48,18 @@ const IdeSideBar = () => {
|
||||
{ sidebarBottomConfig.map((bottomItem, i) => (
|
||||
<TabToggle
|
||||
item={bottomItem}
|
||||
active={ selectedTab === bottomItem.name }
|
||||
onChange={ () => setSelectedTab(bottomItem.name) }
|
||||
active={ state.sideTray[0] === bottomItem.name }
|
||||
onChange={ () => onTabClick(bottomItem.name) }
|
||||
onClick={ onTabClick(bottomItem.name) }
|
||||
key={ 'tab-' + (sidebarTopConfig.length+i) }
|
||||
/>
|
||||
))}
|
||||
</div>
|
||||
</fieldset>
|
||||
{ sidebarCombinedConfig.find(item => item.name === selectedTab)?.panel && (
|
||||
{ selectedTab?.panel && (
|
||||
<div className="w-56 bg-ch-gray-900 text-ch-gray-300 border border-ch-pink-800 border-opacity-30" style={{ height: 'calc(100% - 6px)', margin: '3px'}}>
|
||||
<h2 className="flex items-center h-9 px-4 bg-ch-pink-800 bg-opacity-30">{ selectedTab }</h2>
|
||||
{ sidebarCombinedConfig.find(item => item.name === selectedTab).panel }
|
||||
<h2 className="flex items-center h-9 px-4 bg-ch-pink-800 bg-opacity-30">{ selectedTab.name }</h2>
|
||||
{ selectedTab.panel }
|
||||
</div>
|
||||
) }
|
||||
</section>
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
|
|
||||
import React, { ReactNode } from 'react'
|
||||
import { SvgNames } from 'src/components/Svg/Svg'
|
||||
import { useIdeContext } from 'src/helpers/hooks/useIdeContext'
|
||||
|
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
|
||||
|
||||
interface SidebarConfigType {
|
||||
name: string,
|
||||
@@ -67,7 +68,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: <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
|
||||
panel: <SettingsMenu parentName="Settings"/>,
|
||||
|
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
|
||||
},
|
||||
]
|
||||
|
||||
@@ -76,15 +77,26 @@ 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
|
||||
...sidebarBottomConfig,
|
||||
]
|
||||
|
||||
function 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
|
||||
function SettingsMenu({parentName}: {parentName: string}) {
|
||||
|
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
|
||||
const { state, thunkDispatch } = useIdeContext()
|
||||
|
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="">
|
||||
{ settingsConfig.map(item => (
|
||||
<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-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 }
|
||||
|
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
|
||||
<li className="list-none" 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
|
||||
<button className="px-2 py-2 bg-ch-pink-800 bg-opacity-10 my-px" onClick={() => {
|
||||
|
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
|
||||
console.log('i was clicked')
|
||||
|
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
|
||||
thunkDispatch((dispatch) => dispatch({type: 'settingsButtonClicked', payload:[parentName, 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
|
||||
}} >{ item.title }</button>
|
||||
|
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
|
||||
{ state.sideTray.slice(-1)[0] === item.name && 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
|
||||
</li>
|
||||
|
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} open={state.sideTray.slice(-1)[0] === 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-2 bg-ch-pink-800 bg-opacity-10 my-px"
|
||||
|
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
|
||||
// onClick={() => thunkDispatch((dispatch) => dispatch({type: 'settingsButtonClicked', payload:[parentName, 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
|
||||
// >{ item.title }hi there</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
|
||||
// { state.sideTray.slice(-1)[0] === item.name && 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
|
||||
// {state.sideTray.slice(-1)[0]}
|
||||
|
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
|
||||
))}
|
||||
</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
|
||||
}
|
||||
|
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
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
|
||||
@@ -115,6 +115,7 @@ export interface State {
|
||||
viewerSize: { width: number; height: number }
|
||||
isLoading: boolean
|
||||
threeInstance: RootState
|
||||
sideTray: string[] // could probably be an array of a union type
|
||||
}
|
||||
|
||||
const code = ''
|
||||
@@ -146,103 +147,118 @@ export const initialState: State = {
|
||||
viewerSize: { width: 0, height: 0 },
|
||||
isLoading: false,
|
||||
threeInstance: null,
|
||||
sideTray: [],
|
||||
}
|
||||
|
||||
export const useIdeState = (): [State, (actionOrThunk: any) => any] => {
|
||||
const reducer = (state: State, { type, payload }): State => {
|
||||
switch (type) {
|
||||
case 'initIde':
|
||||
const reducer = (state: State, { type, payload }): State => {
|
||||
console.log('reducing')
|
||||
switch (type) {
|
||||
case 'initIde':
|
||||
return {
|
||||
...state,
|
||||
code:
|
||||
payload.code ||
|
||||
// localStorage.getItem(makeCodeStoreKey(payload.cadPackage)) ||
|
||||
initCodeMap[payload.cadPackage] ||
|
||||
'',
|
||||
ideType: payload.cadPackage,
|
||||
}
|
||||
case 'updateCode':
|
||||
return { ...state, code: payload }
|
||||
case 'healthyRender':
|
||||
const customizerParams: CadhubParams[] = payload?.customizerParams?.length
|
||||
? payload.customizerParams
|
||||
: state.customizerParams
|
||||
const currentParameters = {}
|
||||
customizerParams.forEach((param) => {
|
||||
currentParameters[param.name] =
|
||||
typeof state?.currentParameters?.[param.name] !== 'undefined'
|
||||
? state?.currentParameters?.[param.name]
|
||||
: param.initial
|
||||
})
|
||||
return {
|
||||
...state,
|
||||
objectData: {
|
||||
...state.objectData,
|
||||
type: payload.objectData?.type,
|
||||
data: payload.objectData?.data,
|
||||
},
|
||||
customizerParams,
|
||||
currentParameters,
|
||||
consoleMessages: payload.message
|
||||
? [...state.consoleMessages, payload.message]
|
||||
: payload.message,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'errorRender':
|
||||
return {
|
||||
...state,
|
||||
consoleMessages: payload.message
|
||||
? [...state.consoleMessages, payload.message]
|
||||
: payload.message,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'setCurrentCustomizerParams':
|
||||
if (!Object.keys(payload || {}).length) return state
|
||||
return {
|
||||
...state,
|
||||
currentParameters: payload,
|
||||
}
|
||||
case 'setLayout':
|
||||
return {
|
||||
...state,
|
||||
layout: payload.message,
|
||||
}
|
||||
case 'updateCamera':
|
||||
return {
|
||||
...state,
|
||||
camera: payload.camera,
|
||||
}
|
||||
case 'updateViewerSize':
|
||||
return {
|
||||
...state,
|
||||
viewerSize: payload.viewerSize,
|
||||
}
|
||||
case 'setLoading':
|
||||
return {
|
||||
...state,
|
||||
isLoading: true,
|
||||
}
|
||||
case 'resetLoading':
|
||||
return {
|
||||
...state,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'resetLayout':
|
||||
return {
|
||||
...state,
|
||||
layout: initialLayout,
|
||||
}
|
||||
case 'setThreeInstance':
|
||||
return {
|
||||
...state,
|
||||
threeInstance: payload,
|
||||
}
|
||||
case 'settingsButtonClicked':
|
||||
const isReClick =
|
||||
state.sideTray.length &&
|
||||
state.sideTray.length === payload.length &&
|
||||
state.sideTray.every((original, index) => original === payload[index])
|
||||
if (isReClick) {
|
||||
return {
|
||||
...state,
|
||||
code:
|
||||
payload.code ||
|
||||
// localStorage.getItem(makeCodeStoreKey(payload.cadPackage)) ||
|
||||
initCodeMap[payload.cadPackage] ||
|
||||
'',
|
||||
ideType: payload.cadPackage,
|
||||
sideTray: state.sideTray.slice(0, -1),
|
||||
}
|
||||
case 'updateCode':
|
||||
return { ...state, code: payload }
|
||||
case 'healthyRender':
|
||||
const customizerParams: CadhubParams[] = payload?.customizerParams
|
||||
?.length
|
||||
? payload.customizerParams
|
||||
: state.customizerParams
|
||||
const currentParameters = {}
|
||||
customizerParams.forEach((param) => {
|
||||
currentParameters[param.name] =
|
||||
typeof state?.currentParameters?.[param.name] !== 'undefined'
|
||||
? state?.currentParameters?.[param.name]
|
||||
: param.initial
|
||||
})
|
||||
return {
|
||||
...state,
|
||||
objectData: {
|
||||
...state.objectData,
|
||||
type: payload.objectData?.type,
|
||||
data: payload.objectData?.data,
|
||||
},
|
||||
customizerParams,
|
||||
currentParameters,
|
||||
consoleMessages: payload.message
|
||||
? [...state.consoleMessages, payload.message]
|
||||
: payload.message,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'errorRender':
|
||||
return {
|
||||
...state,
|
||||
consoleMessages: payload.message
|
||||
? [...state.consoleMessages, payload.message]
|
||||
: payload.message,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'setCurrentCustomizerParams':
|
||||
if (!Object.keys(payload || {}).length) return state
|
||||
return {
|
||||
...state,
|
||||
currentParameters: payload,
|
||||
}
|
||||
case 'setLayout':
|
||||
return {
|
||||
...state,
|
||||
layout: payload.message,
|
||||
}
|
||||
case 'updateCamera':
|
||||
return {
|
||||
...state,
|
||||
camera: payload.camera,
|
||||
}
|
||||
case 'updateViewerSize':
|
||||
return {
|
||||
...state,
|
||||
viewerSize: payload.viewerSize,
|
||||
}
|
||||
case 'setLoading':
|
||||
return {
|
||||
...state,
|
||||
isLoading: true,
|
||||
}
|
||||
case 'resetLoading':
|
||||
return {
|
||||
...state,
|
||||
isLoading: false,
|
||||
}
|
||||
case 'resetLayout':
|
||||
return {
|
||||
...state,
|
||||
layout: initialLayout,
|
||||
}
|
||||
case 'setThreeInstance':
|
||||
return {
|
||||
...state,
|
||||
threeInstance: payload,
|
||||
}
|
||||
default:
|
||||
return state
|
||||
}
|
||||
}
|
||||
return {
|
||||
...state,
|
||||
sideTray: payload,
|
||||
}
|
||||
default:
|
||||
return state
|
||||
}
|
||||
|
||||
}
|
||||
export const useIdeState = (): [State, (actionOrThunk: any) => any] => {
|
||||
const [state, dispatch] = useReducer(reducer, initialState)
|
||||
mutableState = state
|
||||
const getState = (): State => mutableState
|
||||
|
||||
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