You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For these, I think it would make sense to use the file name as the component's name, unless the filename is "index.tsx", in which case the containing folder's name should be used. This should cover 99.9% of use cases.
If a component is in the form const ComponentName = (props: SomePropsType) => <div />;, then the const variable's name should be used as the component name.
With react hooks, it is not possible to determine a hooks-based component's state. We can just ignore the state in these cases. If better tooling arises in the future for this from the react team (or a 3rd party), this could be revisited
exportdefault()=>{// Not easy at all to infer these types, especially with custom hooks// that wrap multiple calls to useStateconst[counter,setCounter]=useState(0);return(<div><h1>Count: {counter}</h1><buttononClick={()=>setCounter(counter+1)}>+</button><buttononClick={()=>setCounter(counter-1)}>-</button></div>);}
Example
Input:
interfaceFCProps{text: string}functionFuncComp(props: FCProps){return<span>{props.text}</span>;}interfaceArrowProps{title: string;value: number;}constArrowComp=(props: ArrowProps)=>{return(<div><FuncComptext={props.title}/><span>Value: {props.value}</span></div>);}constNoPropsComp=()=>{return(<div><span>I don't have any props</span></div>);}interfaceClassProps{title: string;}interfaceClassState{value: number;}// Props and state types can be left out here, but it has to be// given if they're being used.classClassCompextendsReact.Component<ClassProps,ClassState>{state={value: 0,};publicrender(){return(<div><ArrowComptitle={this.props.title}value={this.state.value}/><NoPropsComp/><buttononClick={this.onIncrement}>+</button><buttononClick={this.onDecrement}>-</button></div>);}privateonIncrement=()=>{this.setState(prevState=>({value: prevState.value+1}));}privateonDecrement=()=>{this.setState(prevState=>({value: prevState.value-1}));}}
but that seems out of scope for this initial issue, and becomes more complicated with hooks.
Component diagrams could become incredibly large. It is typical for React projects to have a lot of components defined in them. Maybe support a --max-component-depth option or something to work around it?
This would ignore any components that are made using React.createElement, but no one really does that anymore.
Doesn't address how to handle 3rd party components. I'd say ignore them. 3rd party components are often written in JS and shipped with .d.ts files. This would be very difficult to support, and probably wouldn't be very useful anyway.
The text was updated successfully, but these errors were encountered:
I was dusting it off last night as someone brought up a suggestion. I got the dependencies up to date. Plan to start tackling some of these issues which are straight forward.
Opening this issue to request support for TSX files and to create class diagrams for React components.
Main goals
Caveats:
For these, I think it would make sense to use the file name as the component's name, unless the filename is "index.tsx", in which case the containing folder's name should be used. This should cover 99.9% of use cases.
If a component is in the form
const ComponentName = (props: SomePropsType) => <div />;
, then the const variable's name should be used as the component name.With react hooks, it is not possible to determine a hooks-based component's state. We can just ignore the state in these cases. If better tooling arises in the future for this from the react team (or a 3rd party), this could be revisited
Example
Input:
Output:
Not addressed
but that seems out of scope for this initial issue, and becomes more complicated with hooks.
Component diagrams could become incredibly large. It is typical for React projects to have a lot of components defined in them. Maybe support a
--max-component-depth
option or something to work around it?This would ignore any components that are made using
React.createElement
, but no one really does that anymore.Doesn't address how to handle 3rd party components. I'd say ignore them. 3rd party components are often written in JS and shipped with
.d.ts
files. This would be very difficult to support, and probably wouldn't be very useful anyway.The text was updated successfully, but these errors were encountered: