Skip to content
Snippets Groups Projects

Improve completion of emoji and team members

Merged gitlab-qa-bot requested to merge github/fork/riyad/add-completion-for-all-emoji into master

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Created by: dzaporozhets

    I am not sure we need autocomplete for all emotions. Its like overflow.

    By Administrator on 2012-09-30T15:14:03 (imported from GitLab project)

    By Administrator on 2012-09-30T15:14:03 (imported from GitLab)

  • 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: jimmybrancaccio

    I'll go ahead and +1 as well. It's a bit convenient.

    By Administrator on 2012-10-02T17:09:58 (imported from GitLab project)

    By Administrator on 2012-10-02T17:09:58 (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

    I've extracted the auto-completion stuff into a controller added specs and updated the notes' JS accordingly.

    By Administrator on 2012-10-03T01:14:20 (imported from GitLab project)

    By Administrator on 2012-10-03T01:14:20 (imported from GitLab)

  • Created by: riyad

    Also updated the description.

    By Administrator on 2012-10-03T01:21:36 (imported from GitLab project)

    By Administrator on 2012-10-03T01:21:36 (imported from GitLab)

  • Created by: riyad

    Updated to use improvements from #1632

    By Administrator on 2012-10-05T15:12:52 (imported from GitLab project)

    By Administrator on 2012-10-05T15:12:52 (imported from GitLab)

  • Created by: NARKOZ

    I don't think it's worth it. People don't use emoji too often.

    By Administrator on 2012-10-08T09:24:33 (imported from GitLab project)

    By Administrator on 2012-10-08T09:24:33 (imported from GitLab)

  • gitlab-qa-bot
  • gitlab-qa-bot
  • 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)

  • gitlab-qa-bot
  • gitlab-qa-bot
  • gitlab-qa-bot
  • gitlab-qa-bot
  • 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: dzaporozhets

    @Riyad thank you! its more clear now. Can you also squash commits please? @narkoz what do you think? Can we merge it?

    By Administrator on 2012-10-09T12:20:21 (imported from GitLab project)

    By Administrator on 2012-10-09T12:20:21 (imported from GitLab)

  • Created by: riyad

    @randx done :)

    By Administrator on 2012-10-09T12:44:54 (imported from GitLab project)

    By Administrator on 2012-10-09T12:44:54 (imported from GitLab)

  • Created by: NARKOZ

    @randx Yup, can be merged. Personally, I don't think we need it :smiley:

    @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)

  • Created by: dzaporozhets

    :smile:

    By Administrator on 2012-10-12T18:12:33 (imported from GitLab project)

    By Administrator on 2012-10-12T18:12:33 (imported from GitLab)

  • Please register or sign in to reply
    Loading