Skip to content
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

Merged
merged 40 commits into from
Dec 10, 2024
Merged

Feature/blocks #3087

merged 40 commits into from
Dec 10, 2024

Conversation

agalin920
Copy link
Contributor

No description provided.

@agalin920 agalin920 marked this pull request as draft December 3, 2024 21:33
@agalin920 agalin920 marked this pull request as ready for review December 5, 2024 17:59
@agalin920 agalin920 requested a review from finnar-bin December 6, 2024 21:25
@@ -283,10 +283,16 @@ export const Field = ({
return (
<AIFieldShell
ZUID={fieldData?.ZUID}
name={fieldData?.name}
Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same questions for label

Copy link
Contributor

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.

Copy link
Contributor Author

@agalin920 agalin920 Dec 10, 2024

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}`;
Copy link
Contributor

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);
Copy link
Contributor

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.

Copy link
Contributor Author

@agalin920 agalin920 Dec 10, 2024

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(
Copy link
Contributor

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?

Copy link
Contributor Author

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

@shrunyan shrunyan merged commit 3bfe59a into dev Dec 10, 2024
1 check failed
@shrunyan shrunyan deleted the feature/blocks branch December 10, 2024 00:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants