-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
✨ Marketplace
: Add Product#tags
#2190
Conversation
@@ -2,7 +2,7 @@ class Marketplace | |||
class Policy < ApplicationPolicy | |||
def create? | |||
return true if current_person.operator? | |||
return true if current_person.member_of?(marketplace.space) | |||
return true if current_person.member_of?(space) |
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 allows us to have Models
within the Marketplace
that do not reference a Marketplace
directly, such as TaxRate
and Tag
|
||
describe "Product Tags", type: :system do | ||
let(:space) { create(:space, :with_entrance, :with_members) } | ||
let(:marketplace) { create(:marketplace, :ready_for_shopping, room: space.entrance) } |
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 two lines are repeated in pretty much every marketplace/*_system_spec.rb
; maybe we pull them to a mixin?
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 don't have a strong opinion either way.
For tests like these, I don't mind duplicating a couple of lines, and I like seeing at a glance how data is being setup for the test. An intermediate solution would be to have a trait like :with_full_space
on the Marketplace factory that creates a Marketplace with a fully-setup and populated space.
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 the solution of a marketplace
trait for making instantiating a marketplace
in a space with an entrance + members.
sign_in(space.members.first, space) | ||
end | ||
|
||
scenario "Adding Tags to a Product" do # rubocop:disable RSpec/Capybara/FeatureMethods,RSpec/ExampleLength |
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 we should disable both of these cops in system specs. Thoughts?
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.
Yeah, that makes sense.
super(polymorphic_path(object_or_path.location)) | ||
else | ||
super | ||
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.
Technically we don't need this else
in this case; since everything that is visited has a location
but oh well.
23f6ef5
to
115a346
Compare
.gitignore
Outdated
@@ -33,4 +33,4 @@ app/assets/builds/ | |||
|
|||
.devcontainer/output | |||
|
|||
TAGS |
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 was making us ignore the tags
views folder 🤦
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.
TIL .gitignore will look at any directories with a declaration made at the top level 😳
@zspencer can you provide some justification for implementing tags using a relational architecture through a bridge table vs using an array column on a Spitballing...I can imagine a Does my question(ing) make sense? |
To be honest, I don't really think there's enough difference to encourage one or the other in this particular use case. My main goal here was making it so If we were to implement it as a field-on-a-row; we'd need to get into deeper arcana than I think is necessary. |
Marketplace
: First draft of Product#tags
Marketplace
: First draft of Product#labels
A question I think is of greater importance here is what we call these things. So, what should we call them? Do we call them |
Marketplace
: First draft of Product#labels
Marketplace
: Add Product#labels
018ba9f
to
c12f3d3
Compare
@rosschapman - I lied! I forgot that I didn't have clarity on the lesser of N evils, regarding what we call these.
|
Or maybe we just go hella specific and call them |
c12f3d3
to
130e1ba
Compare
- #2189 Lil' quick sketch through the workflow. Only interesting things of note here are I am using `scenario` syntax (which feels better to me, and was validated by @ExMember in antoher context yesterday.) I am also doing something "weird" where I overload the `visit` method to rely on our `Record#location` method to interject a `polymorphic_path` call; saving us the burden of including the `polymorphic_path` call on our own every time we use `visit`; but adding the burden of a layer of indirection. I also did this with `within`, because omg that awkward `"##{dom_id(model)"` drives me nuts every time I type it. It makes me want to scream. I can't stand it.
Products can now be tagged with things like `Gluten Free` or `Vegan`, and will show up as such under Product listings
130e1ba
to
2c17ad2
Compare
Marketplace
: Add Product#labels
Marketplace
: Add Product#tags
The justification is that Rails people have a bizarre kink for bridge tables. 😉 (I hate bridge tables, because I'm not a Real Rails Person.) |
Just to record a brief summary of the convo we just had during ensemble: seems like calling them |
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.
Very nice, thank you!
@@ -0,0 +1,12 @@ | |||
class Marketplace | |||
class Tag < Record |
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.
Not a blocker, but one way to help users keep their tags tidy would be to add a case-insensitive uniqueness constraint here, e.g:
validates :label, uniqueness: true, scope: { :bazaar, case_insensitive: true }
This would prevent adding "Gluten-Free" if "gluten-free" already exists.
(Also a good excuse to start a smol tag_spec.rb
...)
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 enforcing a case insensitive uniqueness scoped to bazaar!
Is it a kink if it's inflicted against our will through trauma... oh wait. |
- zinc-collective#2189 Lil' quick sketch through the workflow. Only interesting things of note here are I am using `scenario` syntax (which feels better to me, and was validated by @ExMember in antoher context yesterday.) I am also doing something "weird" where I overload the `visit` method to rely on our `Record#location` method to interject a `polymorphic_path` call; saving us the burden of including the `polymorphic_path` call on our own every time we use `visit`; but adding the burden of a layer of indirection. I also did this with `within`, because omg that awkward `"##{dom_id(model)"` drives me nuts every time I type it. It makes me want to scream. I can't stand it. * ✨ `Marketplace`: Adds `Product#tags` Products can now be tagged with things like `Gluten Free` or `Vegan`, and will show up as such under Product listings * ✨ `Tag` labels are case insensitive
Marketplace
:Product#tags
#2189Products can now be tagged with things like
Gluten Free
orVegan
,and will show up as such under Product listings
After