Remove step 1 of new object field

[ehconitin]

fixes #7356
fixes #6967
fixes #7102
fixes #7121
fixes #7505

[ehconitin]

@Bonapara removed all the redundant icons code beside breadcrumb! Those Icons are removed right?

[greptile-apps]

PR Summary

This pull request addresses three main issues in the Twenty application's settings pages:

• Improves accessibility by replacing <div> with <a> tags for settings cards
• Simplifies the new field creation process by removing the two-step approach
• Reduces settings page flashing during loading with a skeleton loader

Key changes:

• Introduced SettingsSkeletonLoader component for improved loading experience
• Refactored SettingsObjectNewField to combine field type selection and configuration into a single step
• Removed icons from SubMenuTopBarContainer components across multiple settings pages
• Updated routing to reflect the simplified new field creation process
• Adjusted SettingsDataModelFieldTypeSelect for better accessibility and user experience

_{30 file(s) reviewed, 5 comment(s)
Edit PR Review Bot Settings}

[Bonapara]

@Bonapara removed all the redundant icons code beside breadcrumb! Those Icons are removed right?

Thanks Nitin! Do you have a screenshot so I can better understand what you mean?

[ehconitin]

@Bonapara removed all the redundant icons code beside breadcrumb! Those Icons are removed right?

Thanks Nitin! Do you have a screenshot so I can better understand what you mean?

@Bonapara
There used to be icons here right? and they are now removed I think, because I cant see them even in Figma.
But the code related to it was not cleaned. Just making sure I should clean it or not!

[Bonapara]

Yes you can clean it! Thanks @ehconitin

[FelixMalfait]

Thank you! This works but I feel we could do even better :)

When you open links in a new tab, it's not working because you created fake links to = #
Instead we should probably link to={?fieldType=${key}}
We should also be able to use the backed button (remove replace: true)

And that will be an issue because if you press the back button, configureStep remains with its previous value.
So I would advocate for a bigger refactoring, either keep the current code and drop isConfigureStep to just base it on whether the field type parameter has been provided in the url, or just split into two pages.

Do you see what I mean @ehconitin?

[ehconitin]

@FelixMalfait Yes!
Refactoring it to two separate pages would be much cleaner!
I am dropping isConfigureStep state, its very restrictive.
Couldnt do to={?fieldtype=${key}} because since its the same page, had to add a useEffect to keep listening for url changes, so opted for a onClick navigation, which is kind of a cheap trick.
Will refactor!
Thanks :)

[ehconitin]

@FelixMalfait conflicts made this way more tricky! :(
Refactor is done! Please let me know if I have missed anything.

[ehconitin]

sb-test failed, checking!

[ehconitin]

Ready for review!

[Bonapara]

I just checked from a product perspective, and it looks good! Thanks for the great work, @ehconitin.

[FelixMalfait]

Great work! I think we should merge this as the PR is already big!
One potential improvements would have been to disable the configure step if no fieldType is passed instead of defaulting to text which can sometimes create weird behavior (e.g. you're on step 2 you come back to step 1 via top bar to check what was selected then come back to step 2 via top bar - your field type has changed). Not a big deal / TBC once we have experience with users!

[github-actions]

Thanks @ehconitin for your contribution!
This marks your 43rd PR on the repo. You're top 1% of all our contributors 🎉
See contributor page - Share on LinkedIn - Share on Twitter

[ehconitin]

@FelixMalfait
Ah, I missed that one!
It was already done in #6969 but we scrapped it because keyboard navigation was not required anymore.
I forgot to address it here.
I will address this in some minor fix PR soon!

Thanks!