Conversation
SGD1953
left a comment
SGD1953
left a comment
There was a problem hiding this comment.
The server side part or it looks a bit too complex to me.
| next(); | ||
| }); | ||
|
|
||
| server.get('Event', (req, res, next) => { |
There was a problem hiding this comment.
htmx requires a solid html form which created some trouble with the layout. Other ways would require interfering with the htmx request execution. All the solutions I found were way too complicated for what I want to achieve it, compared to using a GET, although a POST would be logical in regards to the endpoint purpose
There was a problem hiding this comment.
Ok, something we need to look into. In my view we should only jeopardise a clean architecture for very good reasons.
| */ | ||
| function post(req, res, next) { | ||
| if (req.httpMethod === 'POST') { | ||
| if (request.httpMethod === 'POST') { |
There was a problem hiding this comment.
yes, without it POST requests are not working at all. Initially I tried the event as POST.
There was a problem hiding this comment.
sorry my fault. I degutted the SFRA server and rely more on dw standard objects. maybe we can pass in the actual request.
| model = request.custom.model; // eslint-disable-line no-undef | ||
|
|
||
| return ` | ||
| ${hookMgr.callHook('wishlist.template', 'productIcon', model.product.ID)} |
There was a problem hiding this comment.
Maybe I need a bit more explanation, but I'm not sure I'm in love with this hook-pattern. What do we need it for?
There was a problem hiding this comment.
This was intended as idea to have the plugin separated from the storefront cartridge.
In this file here, I just reused it, as it was created already. But looking at the tile partial I wanted to avoid having something like
const heartIcon = require('..../heartIcon');
heartIcon.createModel(....);
heartIcon.template(....);
as this would mess up the storefront with code from my "optional" extension
There was a problem hiding this comment.
I like hooks to be able to place a generic "spot" on a template which a plugin can fill.
Ideally though, we can come up with a way where you "click not code" and drag the individual wishlist controls on the page using page designer
But how would one do this for tiles?
There was a problem hiding this comment.
We could move tiles to OD as well, but currently this would make it super-slow due to the uncached first include. In the meanwhile, the tile could have an array plugins which would accept partials (i.e. via a registerPlugin() method) which would then be rendered at a defined spot. Or alternatively, you could simply extend the tile.
| @@ -0,0 +1,15 @@ | |||
| <isdecorate template="decorator/main"> | |||
There was a problem hiding this comment.
This ISML was just as example placeholder to see the items on the wishlist.
| @@ -0,0 +1 @@ | |||
| <isinclude url="${URLUtils.url('Tile-Show', 'pid', item.productID)}"/> No newline at end of file | |||
There was a problem hiding this comment.
This ISML was just as example placeholder to see the items on the wishlist.
ISML free approach can be taken later.
| @@ -0,0 +1,42 @@ | |||
| <a class="wishlist-header-icon ${pdict.filledWishlistClass}" | |||
There was a problem hiding this comment.
I can port that markup into script.
|
|
||
| const ProductList = require('dw/customer/ProductList'); | ||
|
|
||
| server.get('HeaderIcon', (req, res, next) => { |
There was a problem hiding this comment.
This makes sense, I am just wondering if those header includes do really all need to live in their own include or if we could just have one (which will have Account, Wishlist, Cart etc.)
There was a problem hiding this comment.
For account I use PD to have a "cached" version for guests. Other then that I agree, although it's less of an issue for YSH as we ideally render the header just once per session (if all links are htmxed correctly)
SGD1953
force-pushed
the
feature/wishlist
branch
from
2948dd8 to
d6abe35
Compare
|
@aseyfarth what's the status here, can we get this into a mergeable shape? |
3 participants
No description provided.