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

Marketplace: Add Product#tags #2190

Merged
merged 3 commits into from
Mar 7, 2024
Merged

Conversation

zspencer
Copy link
Member

@zspencer zspencer commented Feb 8, 2024

Products can now be tagged with things like Gluten Free or Vegan,
and will show up as such under Product listings

After

Screenshot 2024-02-08 at 8 40 46 AM

@zspencer zspencer requested review from a team February 8, 2024 16:42
@zspencer zspencer added ✨ feature Reduces Client's Burden or Grants them Benefits 🥗 test automation Adds some automated tests. V nutritious. labels Feb 8, 2024
app/furniture/marketplace/management_component.html.erb Outdated Show resolved Hide resolved
@@ -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)
Copy link
Member Author

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) }
Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member Author

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?

Copy link
Member

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
Copy link
Member Author

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.

@zspencer zspencer force-pushed the marketplace/products-can-be-tagged branch from 23f6ef5 to 115a346 Compare February 8, 2024 16:50
.gitignore Outdated
@@ -33,4 +33,4 @@ app/assets/builds/

.devcontainer/output

TAGS
Copy link
Member Author

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 🤦

Copy link
Contributor

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 😳

@rosschapman
Copy link
Contributor

rosschapman commented Feb 20, 2024

@zspencer can you provide some justification for implementing tags using a relational architecture through a bridge table vs using an array column on a Product? I generally understand the tradeoffs between these two methodologies, so was hoping you could help me understand why you might prefer one way over another for Convene.

Spitballing...I can imagine a Product -> Tags relationship using an array column, that also retains referential integrity if those tags are only chosen via a select dropdown from a pre-filled Tags record table. (Presuming referential integrity being one major benefit to the relational model.) Of course, an underlying question is whether constraining the tags to a strict taxonomy might be preferable over user-generated values?

Does my question(ing) make sense?

@zspencer
Copy link
Member Author

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 Members can decide what Tags are allowed in the Marketplace context. Rails doesn't have great built-in support for searching / filtering by array fields in Postgresql; so this is the "most boring" way to go with it.

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.

@zspencer zspencer changed the title Marketplace: First draft of Product#tags Marketplace: First draft of Product#labels Feb 21, 2024
@zspencer
Copy link
Member Author

A question I think is of greater importance here is what we call these things. label and tag are both methods defined in Rails views.

So, what should we call them? Do we call them tags even though it's a name collision? In the Journal, we call them Keywords... Maybe it's actually Product#features?

@zspencer zspencer marked this pull request as draft February 22, 2024 00:02
@zspencer zspencer changed the title Marketplace: First draft of Product#labels Marketplace: Add Product#labels Feb 22, 2024
@zspencer zspencer force-pushed the marketplace/products-can-be-tagged branch 2 times, most recently from 018ba9f to c12f3d3 Compare February 22, 2024 01:57
@zspencer
Copy link
Member Author

zspencer commented Mar 4, 2024

@rosschapman - I lied! I forgot that I didn't have clarity on the lesser of N evils, regarding what we call these.

  • label feels too generic / collides with HTML
  • tag feels too generic + collides with HTML
  • Maybe badge? or sticker? or is that too skeumorphic?

@zspencer
Copy link
Member Author

zspencer commented Mar 5, 2024

Or maybe we just go hella specific and call them Product#dietary_restrictions for now?

@zspencer zspencer force-pushed the marketplace/products-can-be-tagged branch from c12f3d3 to 130e1ba Compare March 5, 2024 18:44
- #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
@zspencer zspencer force-pushed the marketplace/products-can-be-tagged branch from 130e1ba to 2c17ad2 Compare March 7, 2024 01:16
@zspencer zspencer changed the title Marketplace: Add Product#labels Marketplace: Add Product#tags Mar 7, 2024
@zspencer zspencer marked this pull request as ready for review March 7, 2024 01:51
@anaulin
Copy link
Member

anaulin commented Mar 7, 2024

@zspencer can you provide some justification for implementing tags using a relational architecture through a bridge table vs using an array column on a Product? I generally understand the tradeoffs between these two methodologies, so was hoping you could help me understand why you might prefer one way over another for Convene.

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.)

@anaulin
Copy link
Member

anaulin commented Mar 7, 2024

Or maybe we just go hella specific and call them Product#dietary_restrictions for now?

Just to record a brief summary of the convo we just had during ensemble: seems like calling them tags gives us a bit more flexibility.

Copy link
Member

@anaulin anaulin left a 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
Copy link
Member

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...)

Copy link
Member Author

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!

@zspencer
Copy link
Member Author

zspencer commented Mar 7, 2024

The justification is that Rails people have a bizarre kink for bridge tables. 😉

Is it a kink if it's inflicted against our will through trauma... oh wait.

@zspencer zspencer merged commit 86524fe into main Mar 7, 2024
3 checks passed
@zspencer zspencer deleted the marketplace/products-can-be-tagged branch March 7, 2024 02:42
zspencer added a commit to zinc-collective/tobias that referenced this pull request Mar 25, 2024
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ feature Reduces Client's Burden or Grants them Benefits 🥗 test automation Adds some automated tests. V nutritious.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants