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

Add tooltips to admin calculators #3382

Merged
merged 1 commit into from
Nov 13, 2019
Merged

Add tooltips to admin calculators #3382

merged 1 commit into from
Nov 13, 2019

Conversation

codykaup
Copy link

Description

This change adds tooltips for some calculators in the admin panel. I tried to create some basic text based on the guides so they can easily be changed in the future. If you have further ideas on what these should say, I'm all ears!!

Side Note: Since this is just changing a small piece of the frontend view, I wasn't totally sure on tests as there's no real extra functionality. As always, if you feel there should be some, don't hesitate to let me know!

This PR is in reference to: issue #3363

Thanks in advance!

Quick view of how these look

Screen Shot 2019-10-14 at 9 05 04 PM

Screen Shot 2019-10-14 at 9 04 01 PM

Screen Shot 2019-10-14 at 9 03 40 PM

Checklist:

  • I have followed Pull Request guidelines
  • I have added a detailed description into each commit message
  • I have updated Guides and README accordingly to this change (if needed)
  • I have added tests to cover this change (if needed)

@@ -4,6 +4,7 @@
<div id="preference-settings">
<div class="field">
<%= f.label(:calculator_type, Spree::Calculator.model_name.human) %>
<%= admin_hint t("spree.#{@calculator_type}"), t(@calculator_type, scope: [:spree, :hints, "spree/calculator"]) %>
Copy link
Author

Choose a reason for hiding this comment

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

I couldn't find a great way to grab the parent module of the calculator without it getting hacky so I figured an instance method in the controller would be a decent alternative!

@kennyadsl
Copy link
Member

Hey @codykaup, thanks a lot for the PR. I think this issue was more to explain what every single calculator does, rather than the generic calculator type. Anyway, I think this is still an improvement, and I'd like to go ahead.

What about passing the tooltip content as a partial variable from the outside, for example here, so we don't have to set the instance variable in the controller? This variable could be optional so, when we need to call the partial without the tooltip, we can still do that. What do you think?

@codykaup
Copy link
Author

Hey @codykaup, thanks a lot for the PR. I think this issue was more to explain what every single calculator does, rather than the generic calculator type. Anyway, I think this is still an improvement, and I'd like to go ahead.

What about passing the tooltip content as a partial variable from the outside, for example here, so we don't have to set the instance variable in the controller? This variable could be optional so, when we need to call the partial without the tooltip, we can still do that. What do you think?

Definitely not a bad idea. Do you have a suggestion that would prevent hardcoding the calculator names?

Right now, I'm assuming it would be a new partial that defaults to base_controller unless supplied like promotions:

<%= admin_hint t('spree.adjustment_type'), t(:promotions, scope: [:spree, :hints, "spree/calculator"]), locals: { calculator: "promotions" } %>

@kennyadsl
Copy link
Member

I mean more something like adding the hint we want to show where we call the partial:

<%= render partial: 'spree/admin/shared/calculator_fields', locals: { f: f, hint: : shipping_methods } %>

and into that partial:

<% if local_assigns.has_key? :hint %>
  <%= admin_hint t("spree.#{hint}"), t(hint, scope: [:spree, :hints, "spree/calculator"]) %>
<% end %>

WDYT?

@codykaup
Copy link
Author

I mean more something like adding the hint we want to show where we call the partial:

<%= render partial: 'spree/admin/shared/calculator_fields', locals: { f: f, hint: : shipping_methods } %>

and into that partial:

<% if local_assigns.has_key? :hint %>
  <%= admin_hint t("spree.#{hint}"), t(hint, scope: [:spree, :hints, "spree/calculator"]) %>
<% end %>

WDYT?

I like that idea a lot. It's essentially the same concept without including an instance variable. I just updated my commit to the new version and it works the exact same!

@codykaup
Copy link
Author

Hey @kennyadsl, not sure if you saw or not but the PR has been updated! 🎉

Copy link
Member

@kennyadsl kennyadsl left a comment

Choose a reason for hiding this comment

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

Thanks! @solidusio/core-team can we have a second review, please?

@kennyadsl kennyadsl added Code Review Needed changelog:solidus_backend Changes to the solidus_backend gem labels Nov 13, 2019
Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

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

Thats nice. Thanks

@tvdeyen tvdeyen merged commit c186413 into solidusio:master Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:solidus_backend Changes to the solidus_backend gem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants