Closed jerrytohvan closed 3 years ago
I think this makes sense for the current version.
We're currently working with @alphonseb on a v3 branch where we completely removed the search results page and just kept the autocomplete for now. We're gonna re-introduce the search results page with guidance from @seafoox in the v3, but in the meantime I think this could be merged in the current version.
@alphonseb can I let you take over?
@redox @alphonseb, Thank you for already working on the further version 😄
We've been using the current version and received feedback recently that we are somehow displaying the created_at
and not the most updated version of articles, thus creating the impression that articles were out-dated when its not. Is there a specific timeline regarding the release of v3?:)
@alphonseb, please let me know if this changes is a good patch for now before I merge :)
@jerrytohvan thank you for the contribution!
I took a first look, it seems that showSearchEditAt
would be undefined in the templates.js file. A possible fix could be to transform the instantsearch
object in the templates into a function and pass it the initial options
object.
This is just from a first pass so you would have to check that this doesn't introduce a problem somewhere else.
Thank you for your work on this!
Thanks for the review @alphonseb and I missed that 😅
Edited instantsearch
object in templates.js to pass in options.showSearchEditAt
.
...
hit: showSearchEditAt => compile(
....
<time data-datetime="relative" datetime="[[ ${showSearchEditAt ? 'edited_at_iso' : 'created_at_iso'} ]]"></time>
....
),
....
Also, I've decided to move showSearchEditAt
attribute as a direct child of options
, just so its consistent to other attributes used in the templates.js. Feel free to make changes or merge if its ready according to your team's practice :)
I think having the parameter inside instantsearch
made sense since it's only on the search page. I feel like we could also give it a more obvious name, like useEditedAt
and specify explicitly in the readme that this will replace the current timestamp and not add another one.
One last change needed to make this work is to change the actual calls to the hit
template to pass the parameter down. I think there is one in the instantsearch.js
file but feel free to check if there are other ones I might have missed.
@alphonseb , thanks. Ive amended based on your suggestion, however I didn't manage to setup my local setup to properly test end-to-end. I will need your help here 😅
@jerrytohvan it looks good on my end, could you update the readme to reflect the last changes?
Also, looking at this article, it looks like it would be better to use updated_at_iso
instead of edited_at_iso
for your use case. Can you confirm and make the changes if needed?
@alphonseb , I've just discussed this with our internal Knowledge Base team and we agreed that edited_at
may be the best option for users here. The information i have is that updated_at
captures any changes to article metadata (like moving it to a different section) or even upvoting of articles that can done by users whereas the edited_at
only reflects actual content changes.
This Zendesk help article does a better job of explaining the difference between updated_at and edited_at than the forum thread: https://support.zendesk.com/hc/en-us/articles/228896828-Last-updated-date-discrepancies-in-Help-Center-articles
@alphonseb , readme updated :)
Thanks, looks good to me!
@jerrytohvan released on 2.30.0 🎉 , let me know if you encounter any problem!
@alphonseb , this is great! Thank you for assisting us on this. Looking forward for v3
:D
Hello @redox @LukyVj , I was wondering if we can have the option to list Algolia search hits by
edited_at_iso
instead ofcreated_at_iso
. The reason is the we are able to provide show users recency of updated articles instead of when it was created :)