-
-
Notifications
You must be signed in to change notification settings - Fork 406
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
Custom url navigations #1269
Conversation
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.
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 |
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 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
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.
Great suggestion. I went ahead and made those corrections.
app/models/spina/navigation_item.rb
Outdated
|
||
delegate :menu_title, :materialized_path, :draft?, :homepage?, to: :page | ||
delegate :draft?, :homepage?, to: :page |
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 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.
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 call! That was an oversight on my part. Went ahead and added the allow_nil: true
to take care of this.
test/dummy/db/schema.rb
Outdated
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" |
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.
Why not menu_title
like for pages? How do you handle translations?
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.
We ended up making changes so there is a url_title
attribute that get translated through mobility.
@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
681a0c2
to
83747db
Compare
@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. |
@mattpolito I've noticed some flakiness with a certain Resource test, so I might have to fix that anyway. |
45f091c
to
6cb5783
Compare
@Bramjetten do you have any additional feedback on this one? |
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:
Couple of things I notice in the code:
|
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.
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"?
This can be easily addressed
See above comment regarding toggle/form
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.
We added translations the other day. Did you not see that change or are you referring to something else?
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 agree with this.
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.
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?
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. |
524a4bd
to
ace1394
Compare
ace1394
to
246ec9d
Compare
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? |
How is that working anywhere else? I don't recall seeing that functionality. |
879cd8e
to
972627e
Compare
972627e
to
8f4cdb2
Compare
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 :) |
@Bramjetten is there an example of this workflow currently in the codebase? |
No there isn’t, but the easiest way is to simply loop over all locales in Spina.config.locales and render the fields manually. |
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. |
@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. |
@mattpolito Do you know why the tests are failing? |
@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. |
@Bramjetten suite on this branch was passing. The error that is currently happening seems to have been introduced from #1273 |
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:
Guidance to review
Everything existing functions as normal. All changes are simply additions.