Improve completion of emoji and team members
Created by: riyad
Improves on #1539 and #1551
- Adds completion for all emoji
- Only load auto-completion data if it's actually used (e.g. someone types
@
) This also improves loading times for pages with notes. - Use API for auto-completion of team members
- Introduce the
.gfm-input
class for fields that accept GFM (works only with notes at the moment) and use them for setting up auto-completion.
Preparing the emoji data (when rendering) still slows the request down (try commenting out the call to the helper ;) ). But impact has been minimized by using to_s instead of to_json and doing the format mapping in JS (client-side) instead in Ruby (server-side).
Merge request reports
Activity
Created by: IsNull
I think auto complete is generally a very important feature for good UX. Good UX is the primary factor if a tool like this will be successful in the long turn.
While I agree that autocomplete for emoji is not a primary requirement, it doesn't harm the site or its performance. (Performance would be affected if the autocomplete source is not static)
Anyway, auto complete for Tags are IMHO much more needed. (Every-typo generates a new Tag which is not nice)
So +1 from me :)
By Administrator on 2012-10-02T17:00:48 (imported from GitLab project)
By Administrator on 2012-10-02T17:00:48 (imported from GitLab)
Created by: riyad
@IsNull You are right. Emoji is somewhat of a "hidden feature". And even if you know it exists there is now way you will remember all those names or even look them up every time you want to use them. So this helps to make the feature more visible and usable at the same time. +1 I stand by my MR. ;)
By Administrator on 2012-10-02T21:04:08 (imported from GitLab project)
By Administrator on 2012-10-02T21:04:08 (imported from GitLab)
Created by: riyad
@IsNull about performance: at the moment it hits the disk and gets a list of available emoji every time a page with a comments section is requested. This could also be turned into a static list and updated when there are emoji added or removed.
By Administrator on 2012-10-02T21:08:24 (imported from GitLab project)
By Administrator on 2012-10-02T21:08:24 (imported from GitLab)
Created by: IsNull
@Riyad Advice from a no ruby guy (not yet) :-P
Just load your Emoji's ONCE from the disk into a list. (lazy loading when they are requested first) store them in a list/collection as singleton for the whole application. New Emoji's would require a server restart or any other indicator that the Emoji's list has been outdated.
This way it should be not a big deal. :) The architecture for an intelligent Tag Cache would be slightly more complicated but it can be addressed in a very equal way.
By Administrator on 2012-10-02T21:27:44 (imported from GitLab project)
By Administrator on 2012-10-02T21:27:44 (imported from GitLab)
Created by: riyad
@IsNull Maybe its better to load both users and emoji on demand. So there is no extra cost on the loading time when you are just browsing and hence not using this feature at all. So when you start typing an
@
or:
it would do some ajax magic and load the list only when you when you actually need it.By Administrator on 2012-10-02T21:50:46 (imported from GitLab project)
By Administrator on 2012-10-02T21:50:46 (imported from GitLab)
Created by: riyad
So, what is the reason for that?
- Do people know about it? there are the GFM docs for that.
- Do people know what emoji are available? that's what auto-completion is for.
- Do they care? if not, why have emoji at all? if yes, auto-completion makes this feature more discoverable and user friendly.
And the PR makes it so, that there is no (performance) "penalty" if you don't use it at all. They are only loaded if you type your first
@
or:
respectively.By Administrator on 2012-10-08T15:00:59 (imported from GitLab project)
By Administrator on 2012-10-08T15:00:59 (imported from GitLab)
Created by: riyad
Updated to use API for team member completion. @narkoz Nice work on the API :) Preparing the emoji data still slows the request down (try commenting out the call to the helper). But impact has been minimized by using to_s instead of to_json and doing the format mapping in JS (client-side) instead in Ruby (server-side).
Spec failure is unrelated: the same tests fail on master as well.
By Administrator on 2012-10-08T22:45:22 (imported from GitLab project)
By Administrator on 2012-10-08T22:45:22 (imported from GitLab)
Created by: riyad
@randx @narkoz Updated title and description to state more clearly what this PR changes.
By Administrator on 2012-10-09T12:17:53 (imported from GitLab project)
By Administrator on 2012-10-09T12:17:53 (imported from GitLab)
Created by: NARKOZ
@randx Yup, can be merged. Personally, I don't think we need it
@Riyad thanks.
By Administrator on 2012-10-09T14:10:59 (imported from GitLab project)
By Administrator on 2012-10-09T14:10:59 (imported from GitLab)
Created by: riyad
We implemented it first, but they :facepunch: us in shipping it: https://github.com/blog/1289-emoji-autocomplete :P
By Administrator on 2012-10-12T17:23:04 (imported from GitLab project)
By Administrator on 2012-10-12T17:23:04 (imported from GitLab)