I'm rebuilding from core code with new features and I could use some help...

[thewhiterabbit]

What the heck is going on here?

Adding product types which can be associated with tax and shipping rules.

Adding categories and parented categories, because these are standard organizers that are missing.

Tags, product types, categories, and collections will be able to be added on-the-fly while adding a product, to streamline the process of inventory management.

If a product is being added/updated, when you click on "add tags", "add to category", "add to collection" or edit the product type, it will be as such that if a tag, category, collection, or product type does not exist, it will be created in-line with the product creation. If the tag, category, collection, or product type already exists it will be focused in the selection field as you type it's name.

Renaming "facets" to "tags" and removing their values.

There is no need to have a value field for tags because tags are their own value (they have a slug after all), and facets are implemented in a counterproductive way to modern inventory management.

These changes will be breaking, so a clone has been made that can be later forked/cloned to create a new major Vendure version, if that's something the Vendure team wants to do.

Forking or branching now will not work because this rebuild will be initially destructive and would disrupt current version control, and create non-merging changes.

If this rebuild will be adopted into a new major Vendure version then version control can be picked up from the initial public release commit.

What will remain intact in older data schemas?

• Channels
• Administrators
• Roles
• Shipping methods
• Payment methods
• Tax categories (with possible modifications)
• Tax Rates (with possible modifications)
• Countries
• Zones
• Global settings

What will break in older data schemas?

• Remove Facets, Replace with Tags
• Add Categories, and Category parenting
• Add Product Types
• Replace "Filter by" with "Associate by"
• Add "Associate by tags" to Collections & Categories
• Add "Associate by type" to Collections
• Add "Associate by category" (including parented categories) to Collections
• Require single product type assignment to products before save/update

What will functionally change?

• Product tax dynamically set by product type and channel of sale. (taxes will not be set manually for each product)
• "Assign to Channel" replaced with "Availability"
• Availability doesn't open an overlay. Channels are listed in-line or as a dropdown and, selected or deselected by a single click.
• Price conversion will be dynamic, based on trusted published API conversion rates against the Default Channel currency.
• Price conversion rates will update every day at 00:00:00 GMT
• Price conversion rates table will be manually editable in settings in case of economic crashes or bubbles.
• "Default" Product Details will appear at the top (non-collapsible) with basic information.
• Product Details will include Title/Name, Description, Base Price, Weight, Variation Options, and Assets.
• Clicking "Variation Options" will enable variations and enable the "Add Variant" button, and the Variation Options field.
• Variant Options added to the "default" Product Details will not affect price when selected, and will be available in all Variants.
• Variants will be added to the "default" Product Details like this: color, size, flavor.
• Variant Options will be added like this: color:Blue Green, size:Medium, flavor:Vanilla.
• Creating a new variant will not delete the default variant.
• Product Variants will appear on the same page/tab in an accordion style display.
• Variant Details will expand or collapse so that all, some, only one, or none may be visible as desired.
• Variant Details will include Availability, Tags, Assets, Variation, Price, and inventory management, all with an inherit option.

I know the brief one-liners above lack depth of explanation, but for now that's all I have.

Concept Images and more details are coming soon.

Ideas are warmly welcomed and any help is sincerely appreciated.

There will be a private development git repo until initial public release. If you want to participate in this rebuild please let me know so I can invite you to the private development repo.

[michaelbromley]

Very ambitious plans! The extent of the changes you propose make me suspect that the end result will have diverged so far from this code base that it'll be impossible to reconcile and merge back in (assuming that we wanted to do so).

If you have not done so already, I'd strongly advise that you fully explore whether your needs can be met without requiring modifications to core (i.e. as plugins and admin ui extensions), and if not then via feature requests/pull requests. If you feel this is impossible, then you will end up with a divergent fork of Vendure, and will not benefit from the continued forward progress of the project.

[thewhiterabbit]

I was thinking about your concerns.

The reason for wanting to make these core changes is because potential clients I've talked to want to have a more in-line workflow. I was asked if there was a technical reason why facets should be added separate from products and I couldn't think of a reason. Then I noticed people wanting tags over facets because keyword tagging is organizational and also relates directly to SEO. I think that's a huge gain to be able to directly link product tags with SEO tags using the same data field.

Once I get the concept images done I'll post them here to clarify the changes.

[michaelbromley]

I was asked if there was a technical reason why facets should be added separate from products and I couldn't think of a reason.

There's no technical reason. In fact there is an open feature request for this: #290

Then I noticed people wanting tags over facets because keyword tagging is organizational and also relates directly to SEO.

I'm not sure if I understand the distinction between at "tag" and a "facet", since facets can be seen as tags which are organized into groups. Those groups can represent anything you like.

Once I get the concept images done I'll post them here to clarify the changes.

Ok! I'm interested to see what you come up with 👍

[thewhiterabbit]

The distinction between tags and facets is storage requirement.

Facet requires multidimensional storage.

Tag only requires a single dimension of storage.

To store data for shoe size 27cm in facets you need a record facet keyed as "size" with a set value of "27cm".

To store data for the same in tags you only need to have a single tag called "27cm" stored in the product's "tags" keyed field because we already know 27cm is a size value.

Anything you would use facets for can be done with tags, and at less overhead cost.

[michaelbromley]

What would prevent your client from creating a Facet named "tags" and then allowing any kind of value to go in there?

The structured, grouped nature of Facets is part of their value. For example, when searching products, you can then easily display the available facets in a grouped way, e.g. a search for "LCD monitor" might bring up results with "brand" facets, allowing the customer to filter by "samsung", "LG", "sony" etc. At the same time, there might be a "size" facet, allowing further filtering on "24 inch", "28 inch", "32 inch" etc. Removing that extra dimension mixes all the tags together into a flat list, which is less useful for search filtering.

[thewhiterabbit]

Nothing prevents anyone from using inefficient data storage methods. I'm just saying it's better to use collections for brands and use tags/facets (in a single layer) to identify details about a product outside of the description for more efficient searches. Removing the extra layer will speed searches because you put that layer into another single dimension reference string called a collection.

Mostly everyone knows tags and keywords are synonymous so it's more intuitive than facets IMO. The people I consult with want keyword/tag based identifiers.

Storage space is much cheaper than processing or ram. So, to streamline searches it should be a single layered action as often as possible. When you search for a facet, the machine has to do more work because of the multi-relational and multi layered nature of such searches. The less data, layers, and relations you have to search through, the faster the conclusion and the less resources used.

I had to engineer a database for the aviation industry and I learned a lot about how to make big data very small and fast to search. I've also designed social network data architectures, so I have a little experience in this data architecture arena.

I can make some flow charts, data schema concepts, and UI concept images "tomorrow". It's nearly 5 AM here. I'll be resting soon. Good discussion!

[michaelbromley]

When you search for a facet, the machine has to do more work because of the multi-relational and multi layered nature of such searches. The less data, layers, and relations you have to search through, the faster the conclusion and the less resources used.

Yes, I agree with that. In Vendure we use a search index, which contains a de-normalized (flattened) representation of the facet values which is efficient to search through. When Products are changed (e.g. facets added or removed) then this index gets updated in the background. We also have the ElasticsearchPlugin which does the same, but in an even more efficient manner.

[thewhiterabbit]

Adding tags alongside the facets as a test would be a good first step for my modification.

I love Elasticsearch (not the AWS ripoff). Elasticsearch is great for data that was not already indexed, but what happens when they deprecate something? Why not build flat indexing into the data initially?

Facets are search terms. Search terms are keywords. Keywords are tags. Tags are SEO. Why are tags missing when they are such an important part of current online culture and SEO?

[thewhiterabbit]

Here's the new Add Product layout concept.