This fixes a bug that sometimes boosted statuses being hidden on scrolling.
Previously, we've attached IntersectionObserver twice for boosted statuses:
wrapper Status and wrapped Status. This will call intersection handler twice,
so this may results race condition...probably.
mergeDeep also merges columns, but it should be replaced simply.
So in the new function, first apply mergeDeep except columns, and set default columns if columns unset.
* Sort results by the name
* Switch search method to simple `LIKE` matching instead of tsvector/tsquery
Previously we used scores from ts_rank_cd() to sort results, but it didn't work
because the function returns same score for all results. It's not for calculate
similarity of single words. Sometimes this bug even push out exact matching tag
from results.
Additionally, PostgreSQL supports prefix searching with standard btree index.
Using it offers simpler code, but also less index size and some speed.
* Don't stream toots from users who have blocked the recipient user
This filter was already applied on the `/api/v1/timelines/public` API, but
not yet for the Streaming API.
* Boosted status' account_id doesn't need for filtering in streaming/index.js
This filtering is only for public/hashtag timelines, but boosts already filtered on FanOutOnWriteService because those timelines don't show boosts.
because it may causes flicker on the conversation when it contains blocked/muted user's status.
We use `/api/v1/statuses/{id}/context` to obtain status ids in the
conversation which filters blocked/muted user, but also uses internal
cache constructed from `in_reply_to_id` by `normalizeStatus()` in
`reducers/timelines.js` on each status loading which doesn't filter.
So statuses appears in conversation if those are cached, even those
statuses are from blocked/muted user. Then context cache will be updated
with the result of the context API and those statuses will be removed.
I have left the `normalizeStatus()` function itself which is called many
functions in the file as a placeholder for now, but maybe it should be
removed completely.
I've found this issue when I clicked replies to muted user on the timeline.
Properties I've removed in here were added with lazy loading using
IntersectionObserver (8e4d1cba), but those statuses are not need to be
tracked anyway because it will be rendered as only empty div.
This will reduce requests on who have only few statuses.
- Use next link header to detect more items from first request
- Omit next link header if result items are fewer than requested count
(It had omit it only if result was empty before)
* Add load more button for large screens
* Fix `next` state value on the first loading
* Don't load if `isLoading || !hasMore`
* Start load on near the bottom
Link headers in following/followers API should include follow_id as max_id/since_id.
However, these API use current_user's account_id instead of follow_id from #3167.
This causes irrelevant result on loading more users.
* Always set `overflow: auto` to allow scroll just after opening
* Remove bounce animation which may cause unintended behavior due to max-height
* Use CSS transition instead of react-motion
* Some CSS refactoring including className changing
unarist