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

Pill Component #2123

Merged
merged 31 commits into from
Aug 2, 2017
Merged

Pill Component #2123

merged 31 commits into from
Aug 2, 2017

Conversation

graygilmore
Copy link
Contributor

@graygilmore graygilmore commented Jul 28, 2017

This PR introduces a new "pill" component. This component is used to display the state of something through six distinct colors:

  • Complete
  • Active
  • Inactive
  • Pending
  • Warning
  • Error

This should make scanning tables significantly easier and provide a slightly more modern feel to the admin (looks great with the new tables in #2092).

TODO

  • fix test errors

Style Guide

screen shot 2017-07-28 at 11 32 11 am

Orders (before)

screen shot 2017-07-28 at 11 27 07 am

Orders (after)

screen shot 2017-07-28 at 11 26 11 am

Promotions (before)

screen shot 2017-07-28 at 11 27 25 am

Promotions (after)

screen shot 2017-07-28 at 11 27 48 am

@Mandily
Copy link
Contributor

Mandily commented Jul 28, 2017

I like the content of what you're trying to say in the writeup in the style guide, but could we write it in a clearer way? Maybe something like this:

"Pill styling adds a second, easily scannable way to recognize status. They're most commonly used in, but not restricted to tables."

@tvdeyen
Copy link
Member

tvdeyen commented Jul 28, 2017

I like that! 😍

Maybe it's just me, but shouldn't complete be green? I assume shop owners love to see lots of green in their orders table.

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.

Again, a great improvement. Really appreciate the work went into it 👏

I left some comments about how we should treat presentation of values and re-organizing the git history.

display: inline-block;
padding: 2px 10px;
border-radius: 10px;
font-size: 11px;
Copy link
Member

Choose a reason for hiding this comment

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

The font-size should have a relative unit.
Also the paddings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Any particular reason?

Copy link
Member

Choose a reason for hiding this comment

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

If you raise the body font size you want to grow this as well. The same with the passings. They should be relatively to the font size to keep the ratios.

Copy link
Member

Choose a reason for hiding this comment

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

paddings not passings. (Sorry iOS)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm more curious about who the perspective is here. This is a very specific component that I have sized specifically. If users viewing the admin bump up their font size this will scale along with it.

If we decide to change the root font size of the admin we'll need to go through components one by one and figure out what needs to change. I'd normally be happy to use rem but our admin root font size is 13px which I can see changing in the future but I wouldn't want this component to change.

Copy link
Member

Choose a reason for hiding this comment

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

I like us to move forward to relative units all over the place. That’s the way all frontend frameworks went for a reason.

I see the problem with the small base font size we have. So, I won’t insist to make this change right now.

But, could you please make this font size a variable then?

</td>
<td class="align-center">
<%= promotion.expires_at.to_date.to_s(:short_date) if promotion.expires_at %>
</td>
Copy link
Member

Choose a reason for hiding this comment

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

You are changing the table far more than just adding the pill component. Could you please do this in a separate commit, or not even PR?

usage_limit: Overall Usage Limit
starts_at: Start
status: Status
usage_limit: Usage Limit
Copy link
Member

Choose a reason for hiding this comment

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

These changes do not belong in this PR IMO. At least it should be a separate commit.

end
end
end
end
Copy link
Member

Choose a reason for hiding this comment

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

Could we move this removal in a separate commit after this commit?

@@ -17,10 +17,6 @@ def stock_transfer_edit_or_ship_path(stock_transfer)
end
end

def stock_transfer_status(stock_transfer)
stock_transfer.closed? ? Spree.t(:closed) : Spree.t(:open)
end
Copy link
Member

Choose a reason for hiding this comment

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

this as well, please

@@ -39,7 +39,9 @@
<%= return_item.acceptance_status_errors %>
</td>
<td class-"align-center">
<%= return_item.reception_status.humanize %>
<span class="pill pill-<%= return_item.reception_status %>">
<%= return_item.reception_status.humanize %>
Copy link
Member

Choose a reason for hiding this comment

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

We should only use humanize if we pass it through I18n before and humanize the fallback translation.

Spree.t(return_item.reception_status, 
  scope: 'return_item_reception_statuses', 
  default: return_item.reception_status.humanize)

@@ -38,7 +38,9 @@
<%= return_item.display_amount %>
</td>
<td class="align-center">
<%= return_item.inventory_unit.state %>
<span class="pill pill-<%= return_item.inventory_unit.state %>">
<%= return_item.inventory_unit.state.titleize %>
Copy link
Member

Choose a reason for hiding this comment

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

Same comment as above. I suggest to make a separate commit (not even a PR) first that changes the presentation via I18n.

payment.state,
scope: :payment_states,
default: payment.state
).titleize %>
Copy link
Member

Choose a reason for hiding this comment

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

Ditto

<td class="align-center"><span class="state <%= order.shipment_state %>"><%= Spree.t("shipment_states.#{order.shipment_state}") if order.shipment_state %></span></td>
<td class="align-center">
<span class="pill pill-<%= order.state.downcase %>">
<%= Spree.t("order_state.#{order.state.downcase}").titleize %>
Copy link
Member

Choose a reason for hiding this comment

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

Same comment because of titleization applies here

<% if Spree::Order.checkout_step_names.include?(:delivery) && order.shipment_state %>
<div class="state <%= order.shipment_state %>"><%= Spree.t("shipment_states.#{order.shipment_state}") %></div>
<% end %>
</td>
Copy link
Member

Choose a reason for hiding this comment

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

Should be a separate commit as well

@tvdeyen
Copy link
Member

tvdeyen commented Jul 28, 2017

The build errors are actually related to the reimbursements helper removal.

@Mandily
Copy link
Contributor

Mandily commented Jul 28, 2017

re: "Shouldn't complete be green?"

Green is usually associated with an action - like "go" or "active" in this case. In the case of grey being used for complete, it means that a thing is done and you don't have to worry about doing anything else for it. The colours stand out more than the greys because they're the things still in flux that an admin might want to keep an eye on. The neutral things are the ones they don't have to worry about.

The caveat here being that most if not all of my colour theory is based on North American norms. Maybe these colours mean different things to you.

Make sense?

@graygilmore
Copy link
Contributor Author

graygilmore commented Jul 28, 2017

Maybe it's just me, but shouldn't complete be green? I assume shop owners love to see lots of green in their orders table.

No. Green in this case specifies something that is active. It gives the feeling of movement and that something is currently happening. A complete state is something that needs no further action and is finished, and the grey-blue color better helps signal that.

Edit: ha! Same time as @Mandily.

@tvdeyen
Copy link
Member

tvdeyen commented Jul 28, 2017

Re: Re: Green

This makes total sense. Thanks for the explanation.

This will allow us to better display the status of many of the resources
in a store.
This will give admins a much better idea of the state of each of the
promotions by:

1. Having an "active" or "inactive" column (to use the pill component in a
   later commit.
2. Displaying both the start and end date
3. Reducing the complexity around some of the table header wording
Orders, payments, shipments and other resources have their own states
that need to hook into our new pill component. Instead of modifying each
of these values to line up to our pills' values we can just extend each
of the states through Sass.

Normally I like to avoid using `@extend` but this is the perfect use
case for us.
end
end
context "number" do
let(:text_match_1) { "R123"}

Choose a reason for hiding this comment

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

Space missing inside }.

end
end
context "number" do
let(:text_match_1) { "R123"}

Choose a reason for hiding this comment

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

Space missing inside }.

These are a lot easier to read in the admin if they use the correct
sentence-case structure. This is preferable than modifying the values
directly in the markup with something like `titleize` because that may
not work for different languages.
The state itself is currently being displayed in the admin. Adding a
translation will better help multilingual stores.
This helper file only contained one method that is no longer in use
after switching the state display of a reimbursement to use the pill
component.
@graygilmore
Copy link
Contributor Author

Wooo tests are green. @tvdeyen I think I've addressed all of your other concerns. I went a little overly verbose with the number of commits but that should make things a little cleaner to understand in the future.

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.

These commit messages are perfect. They are really helpful. Thanks for addressing

Great feature 👍

@tvdeyen tvdeyen added changelog:solidus_backend Changes to the solidus_backend gem UI labels Aug 1, 2017
<%= Spree.t(
@order.state,
scope: :order_state,
default: @order.state.humanize
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather not use humanize as a default. We want to see where we are missing translations (and avoid the cost of calling the inflector)

We want to see where we are missing translations (and avoid the cost of
calling the inflector).
@@ -1645,6 +1645,7 @@ en:
pending: Pending
processing: Processing
void: Void
invalid: Invalid
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice! Thanks for that.

@jhawthorn jhawthorn merged commit ec13f80 into solidusio:master Aug 2, 2017
@Eth3rnit3
Copy link

capture d ecran 2017-10-18 a 09 49 22
I have this error message after the update to 2.4 do you have any idea where it might come from?
server-side :
ActionView::Template::Error (".state.sold" failed to @extend ".pill-sold". The selector ".pill-sold" was not found. Use "@extend .pill-sold !optional" if the extend should be able to fail. ): 4: <meta content="width=device-width, initial-scale=1.0, maximum-scale=1" name="viewport"> 5: <%== meta_data_tags %> 6: <%= canonical_tag(current_store.url) %> 7: <%= favicon_link_tag 'favicon.ico' %> 8: <%= stylesheet_link_tag 'spree/frontend/all', media: 'screen' %> 9: <%= csrf_meta_tags %> 10: <%= javascript_include_tag 'spree/frontend/all' %>

@mamhoff
Copy link
Contributor

mamhoff commented Oct 18, 2017

@Eth3rnit3 Have you overridden any style sheets in your host app? Compare them with the ones in Solidus 2.4. You're probably not requiring the pills SCSS file.

@Eth3rnit3
Copy link

yes only the file variables_override. scss I'm going to compare it right now and I'm telling you

@Eth3rnit3
Copy link

no unfortunately the file is empty in solidus

@Eth3rnit3
Copy link

Eth3rnit3 commented Oct 18, 2017

you're right, if I add the line:

@import 'spree/backend/components/pills'

to my file, it works ; -) Thank you

@Eth3rnit3
Copy link

not really sorry, actually.
only a css problem that made a mistake earlier

@Eth3rnit3
Copy link

actually the problem was that I overloaded the $state class in my variables_override file. thank you, maybe we'll see you soon.

@graygilmore graygilmore deleted the pills branch October 19, 2017 16:50
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.

7 participants