-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Pill Component #2123
Conversation
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." |
I like that! 😍 Maybe it's just me, but shouldn't |
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.
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; |
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.
The font-size
should have a relative unit.
Also the paddings.
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.
Any particular reason?
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.
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.
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.
paddings not passings. (Sorry iOS)
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'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.
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 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> |
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.
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 |
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.
These changes do not belong in this PR IMO. At least it should be a separate commit.
end | ||
end | ||
end | ||
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.
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 |
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 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 %> |
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 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 %> |
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.
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 %> |
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.
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 %> |
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.
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> |
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.
Should be a separate commit as well
The build errors are actually related to the reimbursements helper removal. |
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? |
No. Green in this case specifies something that is Edit: ha! Same time as @Mandily. |
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"} |
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.
Space missing inside }.
end | ||
end | ||
context "number" do | ||
let(:text_match_1) { "R123"} |
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.
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.
This is no longer in use after switching this display to use the pill component.
Now that we are using pills in the table it should be much easier to get an idea of the state of an order.
The other states being displayed here can be downright false. If an item has been shipped to the customer and then returned back to the store you would have no way of knowing from this view.
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. |
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.
These commit messages are perfect. They are really helpful. Thanks for addressing
Great feature 👍
<%= Spree.t( | ||
@order.state, | ||
scope: :order_state, | ||
default: @order.state.humanize |
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'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).
core/config/locales/en.yml
Outdated
@@ -1645,6 +1645,7 @@ en: | |||
pending: Pending | |||
processing: Processing | |||
void: Void | |||
invalid: Invalid |
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.
Nice! Thanks for that.
@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. |
yes only the file variables_override. scss I'm going to compare it right now and I'm telling you |
no unfortunately the file is empty in solidus |
you're right, if I add the line:
to my file, it works ; -) Thank you |
not really sorry, actually. |
actually the problem was that I overloaded the $state class in my variables_override file. thank you, maybe we'll see you soon. |
This PR introduces a new "pill" component. This component is used to display the state of something through six distinct colors:
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
Style Guide
Orders (before)
Orders (after)
Promotions (before)
Promotions (after)