Hello !
I wonder how it is possible to use Variants
database structure to do configurable products like :
- Red Color option should be available only if you select XS Size option
- Multiple selection of variations, something like optional products at the end
- Columns/Row price selection (like an Excel : dimension 500/600 = 110 USD whatever)
I'm thinking more at Tesla website or a window configurator (this one seems to do pretty good things : https://fensternorm.com/en/configurator/windows/upvc/trocal-70-eco/c1)
Pretty hard !
I've done some research with the current implementation, and it was wonderful. I really liked the way you did this, simple and clean API.
The first thing I need to do is to add some attributes (something like a description and step order) and prices to this option, like you're doing on Variants. I can maybe add some attributes on options
columns since it's a JSON column, but this might not be a very clean way to do this because I will lose all prices and stock handling of variants, and i don't think i can handle all this things listed above.
So I've considered to requested directly variations this way :
$variants = $product->variantsWhere($this->selection);
// $this->selection is an array of options, handle the same way as variants method of instance Product but return me all available Variants
// Example : $variants = $product->variantsWhere(["Size" => "A", "Color" => "*", "Dimension" => "*"]);
// "*" is when the User haven't yet selected an option, so this line will give me all Variants with `Size === "A"`
Implementation look like this (unfinished) :
public function variantsWhere(array $option)
{
return $this->variants()->where(function ($query) use ($option) {
foreach ($option as $key => $value) {
if ($value !== "*") {
$query->where('option->' . $key, $value);
}
}
return $query;
})->get();
}
This way, I can add more attributes and have pricing, but I wouldn't be able to query : "Select me all variants when there is Size to XS selected" for example.
I think the best way to do this, and for having the more flexibility should be to have a separate table that we can name configurations
with columns option_name|string
, value|string
, description|string
, prices|json
, inventory|json
, product_id
.
Data will look this way (note that i've added some extra columns for illustrate application logic used by the application after Bazar Framework) :
option_name |
value |
description |
price |
inventory |
product_id |
available_on_option_name |
next_step |
order |
Size |
XS |
Little |
10% |
|
|
All |
Color |
1 |
Size |
S |
A bit moe bigger |
10 |
|
|
All |
Color |
1 |
Size |
L |
link |
100 |
|
|
All |
Color |
1 |
Color |
red |
|
10% |
|
|
Size |
Dimension |
2 |
Color |
blue |
|
10 |
|
|
Size |
Dimension |
2 |
Color |
green |
|
100 |
|
|
Size |
Dimension |
2 |
Using another table should be more flexible, right ? But it really looks like variations in fact, except that we don't use the options column of products for query variations. In the other side configurations will be query using $product->configurations()->where('order', 1)->andGetMeArrayValuesWithStepName().
Not tested at all ! But it should be more flexible. I think I described the idea correctly.
So the response seems to be "No.". But I wanted to share my reflection and ask if it's something that should be added on Bazar Framework ? I'm mainly curious about the roadmap where you mention More flexible option/property management
. Are you thinking of something similar or another way ?
Perfect occasion to say that you did an amazing clean work. I learn a lot !
Pretty big question ! Thank you for reading and feel free to close if it's out of the scope.