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

967: displaying the navbar conditionnaly #968

Merged
merged 6 commits into from
May 29, 2021

Conversation

vurtn
Copy link
Contributor

@vurtn vurtn commented May 23, 2021

Sorry for my english.

Why

We need to have the logic about displaying the navbar in one place and not spread all over the controllers (#967).

What

  • Add a NavbarHelper
  • Add a method in application controller that call the NavbarHelper
  • Add the call of the method in controller around the navbar in the layout
  • Remove the layout without the navbar
  • Remove the code in the controllers about the old logic
  • Add tests in navbar_helper_spec.rb

How

I added the function about displaying the navbar in the application_controller because with the inheritance, all controllers will have it. Then i created a NavbarHelper which have the list of the pages concerned about the option and return true or false if the navbar can be display.

Testing

Tests about the navbar helper are in spec/helpers/navbar_helper_spec.rb

Next Steps

I add the current pages (main branch) in the hash and some of them are deleted in others issue (not closed). That's allow us to see clearly what pages had maybe a problem. It should be updated (and close the other issues).

Outstanding Questions, Concerns and Other Notes

Not seem to be concerned.

Accessibility

Not seem to be concerned.

Security

Not seem to be concerned.

Meta

Not seem to be concerned.

Pre-Merge Checklist

I think the reviewer will check this so i let it empty.

  • Security & accessibility have been considered
  • Tests have been added, or an explanation has been given why the features cannot be tested
  • Documentation and comments have been added to the codebase where required
  • Entry added to CHANGELOG.md if appropriate
  • Outstanding questions and concerns have been resolved
  • Any next steps have been turned into Issues or Discussions as appropriate

Copy link
Collaborator

@h-m-m h-m-m left a comment

Choose a reason for hiding this comment

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

Hi, @gamecat2d !

Thanks for helping with this. I feel like you really understood some of the suggestions from #966, and I appreciate seeing the tests here. I had a few suggestions for your code. Let me know what you think!

private

# TODO: this appears to be unused?
def user_not_authenticated(_exception)
def user_not_authenticated(exception)
Copy link
Collaborator

Choose a reason for hiding this comment

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

When you have a moment, please undo this change. We begin variable names with _ like this in methods where we have to accept an argument but we do not care about its value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done 👍

Comment on lines 8 to 9
hidden_places = {}
hidden_places['announcements'] = ['new', 'create']
Copy link
Collaborator

Choose a reason for hiding this comment

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

This may be easier to read if you make it a constant. In additional to being easier to read, it should also use RAM more efficiently.

Unrelated, I wonder if we can also think of a better name than HIDDEN_PLACES

HIDEABLE_NAVBAR_ACTIONS?
CAN_HIDE_NAVBAR_FOR?
NAVBAR_HIDEABLE?
Or, since the module is already called NavbarHelper, maybe NavbarHelper::HIDEABLE_ACTIONS? HIDEABLE_ROUTES?

I like using terms that are going to make sense to a lot of different people, so I definitely would like your opinion on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done with NAVBAR_HIDEABLE 👍

@@ -1,8 +1,6 @@
# frozen_string_literal: true

class ThankYouController < PublicController
layout 'without_navbar'
Copy link
Collaborator

Choose a reason for hiding this comment

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

I always like seeing cleanup like this!

end

it "should return true for the pages not concerned by the displaying option" do
expect(subject.show_navbar?('always_display', 'the_navbar', settings))
Copy link
Collaborator

Choose a reason for hiding this comment

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

It might be good here to display data that's more realistic so people can read the test to know what our goals are. For example, setting the first two arguments to fake_test_controller and index might be a better example. Or maybe always_displayed_controller? Whatever you'd like

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done 👍

Copy link
Collaborator

@solebared solebared left a comment

Choose a reason for hiding this comment

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

This is looking great @gamecat2d , much better than the existing solution.
A couple of thoughts below. Thanks!

Comment on lines 41 to 44
def shown?
NavbarHelper.show_navbar?(params[:controller], params[:action], context.system_settings.display_navbar?)
end

Copy link
Collaborator

Choose a reason for hiding this comment

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

I like this direction because it means show_navbar? doesn't need to be mixed into every controller.

Pushing that logic a bit further, i don't think we really need the shown? method either.

We could instead move this logic directly into layouts/application.html.erb since that's the only place it is used:

  <%# layouts/application.html.erb %>
  <% if shown_navbar? controller_name, action_name, context.system_settings.display_navbar? %>
    <%= render "layouts/navbar" %>
  <% end %> 

This way, nothing extra is added to ApplicationController.

Note also the use of controller_name and action_name above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done 👍

@@ -0,0 +1,20 @@
module NavbarHelper
Copy link
Collaborator

Choose a reason for hiding this comment

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

The way we're using this module, i don't think it belongs in app/helpers, which have a specific usage pattern in rails.
I'd consider moving this to app/lib and naming it NavbarVisibility or some such.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done and now i understand the difference between Helpers directory and lib ! 👍

@@ -0,0 +1,20 @@
module NavbarHelper
def self.show_navbar?(controller, action, settings)
Copy link
Collaborator

Choose a reason for hiding this comment

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

The param name settings here is ambiguous. From looking at how it's called, i see it comes from context.system_settings.display_navbar?. Perhaps we name it display_navbar to match? Open to other suggestions as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done 👍

Copy link
Collaborator

@solebared solebared left a comment

Choose a reason for hiding this comment

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

Great adjustments, thank you! I had an idea for one small refactoring but it is completely optional and we can definitely merge as is, once the merge conflicts are resolved.

Comment on lines 11 to 14
def self.shown_navbar?(controller, action, display_navbar)
always_display = NAVBAR_HIDEABLE[controller].nil? || !NAVBAR_HIDEABLE[controller].include?(action)
always_display || display_navbar
end
Copy link
Collaborator

Choose a reason for hiding this comment

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

One minor refactoring i might suggest:

Suggested change
def self.shown_navbar?(controller, action, display_navbar)
always_display = NAVBAR_HIDEABLE[controller].nil? || !NAVBAR_HIDEABLE[controller].include?(action)
always_display || display_navbar
end
def self.shown?(controller, action, display_navbar)
display_navbar || !hidden?(controller, action)
end
def self.hidden?(controller, action)
NAVBAR_HIDEABLE[controller]&.include?(action)
end
  • Since we're now using the method with the fully qualified module name, i think we don't need navbar in the method name
  • Starting the conditional with display_navbar || helps to clarify that the system system takes precedence over controller/action specific checks
  • IMO, extracting the small hidden? method helps to simplify and make obvious the overall logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right ! Done.

Comment on lines 6 to 8
<% if NavbarVisibility.shown_navbar?(controller_name, action_name, context.system_settings.display_navbar?) %>
<%= render "layouts/navbar" %>
<% end %>
Copy link
Collaborator

Choose a reason for hiding this comment

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

💯

@h-m-m h-m-m merged commit 6403402 into rubyforgood:main May 29, 2021
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