-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/blocks #3087
Feature/blocks #3087
Conversation
@@ -283,10 +283,16 @@ export const Field = ({ | |||
return ( | |||
<AIFieldShell | |||
ZUID={fieldData?.ZUID} | |||
name={fieldData?.name} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change strike me as odd. How does this relate to blocks? How is the name
variable available? If it was already available, why add it now as an or condition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same questions for label
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm seeing that this component is being used in the blocks app. I guess I'm not sure why there is a difference in the props.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. Yes the name and label are passed as props from parent but in this datatype field we ignore those props and get the same data directly from the field data.
Why this was problematic for blocks is because there is a custom field for "variant title" and it should respect the parent props as it is not a field actually existent in the model
Reasoning why I didn't opt to go fully for dropping fieldData?.name in favor for name is to minimize code change footprint and any potential edge cases
|
||
url = `${url}?_bypassError=true&__version=${props.version}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be extracted? Are there other code paths that need item URL determination?
import noSearchResults from "../../../../../../../../public/images/noSearchResults.svg"; | ||
import blockPlaceholder from "../../../../../../../../public/images/blockPlaceholder.png"; | ||
export const BlockTabs = (props: any) => { | ||
const [value, setValue] = useState(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is hard to understand immediately. "Value" is to generic. What is the context of this value?
This jumped out to me when it is equated later. value == 0
. Very hard to know what that means beyond it's literal evaluation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. Used for active tab state but yea not clear.
@@ -78,7 +79,13 @@ export const DuplicateItemDialog = ({ onClose }: DuplicateItemProps) => { | |||
}) | |||
.unwrap() | |||
.then((res) => { | |||
history.push(`/content/${modelZUID}/${res.data.ZUID}`); | |||
history.push( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the second place I've seen this logic. Should this be extracted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shrunyan Good point. Extracting these into url generator helper functions would be a great idea
No description provided.