[WIP]: Fulltext search (#8381) #8714
Conversation
…ignment [FIX] message actions over unread bar
[FIX] popover position on mobile
* Fix hyperlink style on sidebar footer * fix a selector
[FIX] search results position on sidebar
…ents [FIX] sidebar paddings
…ow-rocketDebug [FIX] Window exception when parsing Markdown on server
Hide flex-tab close button
…e-api-notifications [FIX] Remove break change in Realtime API
[FIX] Fix livechat toggle UI issue
[FIX] Fix google play logo on repo README
…irst-load [FIX] Show leader on first load
[DOCS] Add native mobile app links into README and update button images
[FIX] Create channel button on Firefox
[FIX] Broken emoji picker on firefox
…placeholders [FIX] Fix placeholders in account profile
[FIX] Document README.md. Drupal repo out of date
[FIX] username ellipsis on firefox
[FIX] OTR buttons padding
[FIX] status and active room colors on sidebar
…list [FIX] Fix the status on the members list
…de-render [FIX] Markdown being rendered in code tags
[FIX] Small alignment fixes
|
I’ll do a rebase soon, that will make it easier. Was in a hurry yday. It’s actually currently only two packages. |
…ext-search -X theirs
|
@geekgonecrazy @graywolf336 merged |
Regarding UI I know the sidebar is changing. I think search will move to the top and it may become a bit more fitting for global. But at any rate I think for the scope of implementing search providers and search provider api's we should provide methods to be called to perform the search, but we should not go so far as to hook into the UI. This way the frontend guys can work with designers to get that all figured out. |
| */ | ||
| class RedlinkSearchProviderUi extends SearchProviderUi { | ||
|
|
||
| } |
There was a problem hiding this comment.
If implemented what would this do beyond the settings exposed?
There was a problem hiding this comment.
@geekgonecrazy there are usecases where a search provider has own capabilities, such as filtering, facetting, more-like-this, ...
A generic UI would have to be highly configurable in order to deal with all the different options - and it would be tricky to get all providers aligned.
In addition to that, not all provides might be able to integrate with blaze. In this case, they could provide an empty template with a unique selector and provide the UI from the external system (loaded lazily). This makes the provider independent from RC-releases as well.
There was a problem hiding this comment.
@graywolf336 thoughts? 🔝 this is going to be important across various parts of rocketchat apps.
Also we don't want to count on blaze.... as we might be switching frameworks. So something agnostic would be best if this is needed.
There was a problem hiding this comment.
@geekgonecrazy one more thing about that: many external systems (which are to be integrated) already bring some sort of UI. For search, there are plenty of libs. None of them is written in blaze. Thus, a template which loads the other technology‘s UI onCreated is at least something to consider. As you said: also for the RC apps. See https://github.com/assistify/Rocket.Chat/blob/develop/packages/assistify-ai/client/views/app/tabbar/smarti.js
|
@mrsimpson do we want to close this in favor of #10110 ? |
|
Of course! This one is kind-of the forerunner ;) Looking so much forward to seeing #10110 merged! |
@geekgonecrazy this PR is only used to discuss WIP of search interface and sample implementation
Addresses RocketChat/feature-requests#745