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

Custom url navigations #1269

Merged
merged 26 commits into from
Aug 22, 2023
Merged

Conversation

vanillaHafer
Copy link
Contributor

Context

Currently, Spina::NavigationItems can only link to other main Spina pages and they cannot be edited. It would be nice if Custom URLs were able to be added in, to allow more customization to the user.

Changes proposed in this pull request

The 2 main changes in this PR are:

  1. Being able to edit existing navigation items
image 2. Being able to use custom URLs with their labels, instead of having to select from the list of pages image

Guidance to review

Everything existing functions as normal. All changes are simply additions.

Copy link
Contributor

@Bramjetten Bramjetten left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! I like the idea here, but I'm not sure about the UI implementation yet. Few things to consider:

  • How do you handle translations? This goes for the label, but also the URL
  • Instead of having a button "Add menu item", perhaps it should be two buttons: "Add page" and "Add URL" which will then have their own forms.

@@ -25,6 +25,14 @@ def menu_title
end
end

def materialized_path
Copy link
Contributor

Choose a reason for hiding this comment

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

This could be rewritten as:

def materialized_path
  page&.materialized_path || url
end

or like this if you prefer something a bit more explicit:

def materialized_path
  return page.materialized_path if page
  url
end

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great suggestion. I went ahead and made those corrections.


delegate :menu_title, :materialized_path, :draft?, :homepage?, to: :page
delegate :draft?, :homepage?, to: :page
Copy link
Contributor

Choose a reason for hiding this comment

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

I think these also need their own method now, defaulting to false when there's no page. We might be able to get away with allow_nil: true here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call! That was an oversight on my part. Went ahead and added the allow_nil: true to take care of this.

t.integer "navigation_id", null: false
t.integer "position", default: 0, null: false
t.string "ancestry"
t.datetime "created_at", precision: nil
t.datetime "updated_at", precision: nil
t.string "url"
t.string "url_label"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not menu_title like for pages? How do you handle translations?

Copy link
Contributor

Choose a reason for hiding this comment

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

We ended up making changes so there is a url_title attribute that get translated through mobility.

@mattpolito
Copy link
Contributor

  • Instead of having a button "Add menu item", perhaps it should be two buttons: "Add page" and "Add URL" which will then have their own forms.

@Bramjetten I guess it depends on if we have that design language elsewhere in the site. Personally I would think that I'm going to this section to add a navigation item... so already the language of "Add menu item" differs but at least it's a singular thing. If we add choices here, I would think that someone would always choose "Add URL" as it makes the most sense for a nav item.

For confusion sake, I would suggest that there be a single link to open a form where you'd then choose the kind of thing you want to create. In the end you're always creating "A menu item".

* URL string field
* URL Label string field
* Use the page menu title if it has a page, otherwise use the url_label
* url && url_label
* url || page_id
* page_id is now optional
* url_placeholder
* url_label_placeholder
* Now uses toggleComponenet
* Can now use custom urls
@vanillaHafer vanillaHafer force-pushed the custom-url-navigations branch 4 times, most recently from 681a0c2 to 83747db Compare July 25, 2023 21:02
@mattpolito
Copy link
Contributor

@Bramjetten Also we noticed that a test failure was introduced by a previous commit so you'll see the fix for that in here as well.

@Bramjetten
Copy link
Contributor

@mattpolito I've noticed some flakiness with a certain Resource test, so I might have to fix that anyway.

@mattpolito
Copy link
Contributor

@Bramjetten do you have any additional feedback on this one?

@Bramjetten
Copy link
Contributor

I would very much like to have this feature, so let's work on getting it in Spina!

Couple of things I notice in the UI in no particular order:

  • The "Choose page" select is a simple dropdown which is hard to use when you have many pages. Maybe we can borrow PageLink's select with search functionality.
  • Using a toggle to switch forms feels odd. Also, the window jumps when you do that.
  • The input fields don't have autofocus
  • Perhaps instead of a toggle, it can simply be a link to a different form
  • There's no validation on adding a URL
  • It doesn't support translations
  • If you can change the label for custom URLs, shouldn't you be able to do that for pages as well?
  • I feel the navigation items themselves should have a little indicator to tell you it's a custom URL and not a page

Couple of things I notice in the code:

  • Why not use/update the SwitchComponent?
  • Can we have one migration instead of two?
  • Instead of altering navigation_item_params in the controller, I'd prefer to use Turbo Frames to change the form instead of showing/hiding input fields with JS.

@mattpolito
Copy link
Contributor

mattpolito commented Jul 27, 2023

  • The "Choose page" select is a simple dropdown which is hard to use when you have many pages. Maybe we can borrow PageLink's select with search functionality.

I completely agree with this needing improvement. However it is not part of adding a custom url so I'd leave it for another PR.

  • Using a toggle to switch forms feels odd. Also, the window jumps when you do that.

Clearly you haven't been a fan of the toggle and I don't think a separate button is the right choice either. How do you feel about that modal opening with tabs? One for "Page" and another for "URL"?

  • The input fields don't have autofocus

This can be easily addressed

  • Perhaps instead of a toggle, it can simply be a link to a different form

See above comment regarding toggle/form

  • There's no validation on adding a URL

Technically there is a validation. At least one that says it has to be populated if you select the custom url option. Are you referring to something more specific validating the URL itself? Also due to how modals are implemented currently, It does not allow for errors to come back from turbo. We've been wanting to address this anyway. Again, I think that'd be change but not part of this PR.

  • It doesn't support translations

We added translations the other day. Did you not see that change or are you referring to something else?

  • If you can change the label for custom URLs, shouldn't you be able to do that for pages as well?

We didn't make that change because currently you have the mechanism to change a page label on the page itself. Not sure if we want to immediately tackle this but we think it should actually live here in the navigation item. That way we get a uniform experience as well as the ability to have have pages in multiple navigations that can have a different name than the singular one defined on the page.

  • I feel the navigation items themselves should have a little indicator to tell you it's a custom URL and not a page

I agree with this.

  • Why not use/update the SwitchComponent?

If you don't like the toggle, then there's no reason to use the switch component. So we just need to make a decision on UX.

  • Can we have one migration instead of two?

We CAN however we're addressing two different tables so it seems appropriate to have two different migrations. With that said... Is there a reason we're using integer migration versions vs timestamp?

  • Instead of altering navigation_item_params in the controller, I'd prefer to use Turbo Frames to change the form instead of showing/hiding input fields with JS.

This again refers to the decision that needs to be made about the UX.

Overall... we can get the changes in that we all agree on and let's discuss how you feel about the form UX so we can move forward with the other changes.

@vanillaHafer vanillaHafer force-pushed the custom-url-navigations branch 3 times, most recently from 524a4bd to ace1394 Compare July 31, 2023 15:38
@vanillaHafer
Copy link
Contributor Author

I went ahead and implemented those UI changes, so hopefully they are looking more like what you were expecting.

Removed tabs in favor of links

image image

Changed indicator

image

Translations

As far as translations go, we're handling translations for the UI elements the same as all the other elements, by adding to the .yml files under config/locales/. And then regarding actual URL Title translations we are using a translation table for navigation items. As far as we understand, that's enough to handle translations, but please let us know if we are missing something.

@Bramjetten
Copy link
Contributor

This is great!

What I mean with the translations is that I don't think the UI currently supports editing multiple translations. How can end-users add multiple translations for a menu item?

@mattpolito
Copy link
Contributor

How can end-users add multiple translations for a menu item?

How is that working anywhere else? I don't recall seeing that functionality.

@Bramjetten
Copy link
Contributor

How is that working anywhere else? I don't recall seeing that functionality.

CleanShot 2023-07-31 at 21 23 05@2x

@vanillaHafer
Copy link
Contributor Author

Since we don't use translations for our application, the translation feature was a bit foreign to us. Thanks for being patient with us as we learn more about Spina to get this feature rolling.

Looking at the current implementation I was able to throw something together for the Navigations/Navigation Items.

As you can see on the Navigations screen we now have a Translation Component in the upper right:
image

Which will display Navigation Items using their correct translations:
image

When adding in a navigation, we can choose which translation we are adding:
image

After adding in a navigation item and giving it, say, an English translation first, we can now see that some translations are missing url_titles:
image

Which is also seen when editing that particular navigation item:
image

As usual, please give us any feedback you have on this so we can correct anything you think should change!

@Bramjetten
Copy link
Contributor

I think we can improve the UI for switching locales. I think it’s best if we make it possible to fill in all translations in one go, as that’s probably the most common workflow. Perhaps for now it’s best to simply list the different locale fields from top to bottom and improve the UI further in a different PR. That way we can get this merged now and enable it for everyone :)

@mattpolito
Copy link
Contributor

I think it’s best if we make it possible to fill in all translations in one go, as that’s probably the most common workflow.

@Bramjetten is there an example of this workflow currently in the codebase?

@Bramjetten
Copy link
Contributor

No there isn’t, but the easiest way is to simply loop over all locales in Spina.config.locales and render the fields manually.

@mattpolito
Copy link
Contributor

mattpolito commented Aug 14, 2023

Since that is a new UI concept, I would really suggest it be separate from this PR. The data flow wouldn't change so doing it at a later time would not make a difference.

That request feels like a change that should be done across the entire UI.

@Bramjetten
Copy link
Contributor

@mattpolito Agreed that we can merge this into the main branch now and clean up the UI in a separate PR. I’ll create an issue for it.

@Bramjetten
Copy link
Contributor

@mattpolito Do you know why the tests are failing?

@mattpolito
Copy link
Contributor

@Bramjetten thats an interesting failure. I'll look at it or have @vanillaHafer double check it. It's failing on Minitest so it may be a CI issue.

@mattpolito
Copy link
Contributor

@Bramjetten suite on this branch was passing. The error that is currently happening seems to have been introduced from #1273

@Bramjetten Bramjetten merged commit 919e649 into SpinaCMS:main Aug 22, 2023
0 of 2 checks passed
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