2017-05-03 09:04:16 +09:00
import React from 'react' ;
2016-08-25 00:56:44 +09:00
import ImmutablePropTypes from 'react-immutable-proptypes' ;
2017-04-22 03:05:35 +09:00
import PropTypes from 'prop-types' ;
2016-11-17 01:20:52 +09:00
import Avatar from './avatar' ;
2017-05-03 18:43:37 +09:00
import AvatarOverlay from './avatar_overlay' ;
2016-11-17 01:20:52 +09:00
import RelativeTimestamp from './relative_timestamp' ;
import DisplayName from './display_name' ;
import StatusContent from './status_content' ;
import StatusActionBar from './status_action_bar' ;
2022-12-01 01:25:36 +09:00
import StatusReactions from './status_reactions' ;
2018-03-08 12:54:26 +09:00
import AttachmentList from './attachment_list' ;
2018-10-28 14:35:03 +09:00
import Card from '../features/status/components/card' ;
2020-06-26 05:43:59 +09:00
import { injectIntl , defineMessages , FormattedMessage } from 'react-intl' ;
2017-05-03 09:04:16 +09:00
import ImmutablePureComponent from 'react-immutable-pure-component' ;
2019-08-24 05:38:02 +09:00
import { MediaGallery , Video , Audio } from '../features/ui/util/async-components' ;
2017-10-06 08:07:59 +09:00
import { HotKeys } from 'react-hotkeys' ;
import classNames from 'classnames' ;
2019-02-01 08:14:05 +09:00
import Icon from 'mastodon/components/icon' ;
2022-12-02 07:30:39 +09:00
import { displayMedia , visibleReactions } from '../initial_state' ;
2020-09-28 20:29:43 +09:00
import PictureInPicturePlaceholder from 'mastodon/components/picture_in_picture_placeholder' ;
2017-07-08 07:06:02 +09:00
// We use the component (and not the container) since we do not want
// to use the progress bar to show download progress
import Bundle from '../features/ui/components/bundle' ;
2016-08-25 00:56:44 +09:00
2018-08-27 00:53:26 +09:00
export const textForScreenReader = ( intl , status , rebloggedByText = false ) => {
2018-08-24 03:56:57 +09:00
const displayName = status . getIn ( [ 'account' , 'display_name' ] ) ;
const values = [
displayName . length === 0 ? status . getIn ( [ 'account' , 'acct' ] ) . split ( '@' ) [ 0 ] : displayName ,
2018-08-27 00:53:26 +09:00
status . get ( 'spoiler_text' ) && status . get ( 'hidden' ) ? status . get ( 'spoiler_text' ) : status . get ( 'search_index' ) . slice ( status . get ( 'spoiler_text' ) . length ) ,
2018-08-24 03:56:57 +09:00
intl . formatDate ( status . get ( 'created_at' ) , { hour : '2-digit' , minute : '2-digit' , month : 'short' , day : 'numeric' } ) ,
status . getIn ( [ 'account' , 'acct' ] ) ,
] ;
if ( rebloggedByText ) {
values . push ( rebloggedByText ) ;
}
return values . join ( ', ' ) ;
} ;
2019-05-26 20:48:16 +09:00
export const defaultMediaVisibility = ( status ) => {
if ( ! status ) {
return undefined ;
}
if ( status . get ( 'reblog' , null ) !== null && typeof status . get ( 'reblog' ) === 'object' ) {
status = status . get ( 'reblog' ) ;
}
return ( displayMedia !== 'hide_all' && ! status . get ( 'sensitive' ) || displayMedia === 'show_all' ) ;
} ;
2020-06-26 05:43:59 +09:00
const messages = defineMessages ( {
public _short : { id : 'privacy.public.short' , defaultMessage : 'Public' } ,
unlisted _short : { id : 'privacy.unlisted.short' , defaultMessage : 'Unlisted' } ,
private _short : { id : 'privacy.private.short' , defaultMessage : 'Followers-only' } ,
2022-04-29 07:24:31 +09:00
direct _short : { id : 'privacy.direct.short' , defaultMessage : 'Mentioned people only' } ,
2022-01-20 06:37:27 +09:00
edited : { id : 'status.edited' , defaultMessage : 'Edited {date}' } ,
2020-06-26 05:43:59 +09:00
} ) ;
2018-09-15 00:59:48 +09:00
class Status extends ImmutablePureComponent {
2017-04-22 03:05:35 +09:00
2017-05-12 21:44:10 +09:00
static contextTypes = {
2017-05-21 00:31:47 +09:00
router : PropTypes . object ,
2022-12-04 21:33:47 +09:00
identity : PropTypes . object ,
2017-05-12 21:44:10 +09:00
} ;
static propTypes = {
status : ImmutablePropTypes . map ,
account : ImmutablePropTypes . map ,
2023-04-24 15:07:03 +09:00
previousId : PropTypes . string ,
nextInReplyToId : PropTypes . string ,
rootId : PropTypes . string ,
2018-10-20 09:23:58 +09:00
onClick : PropTypes . func ,
2017-05-12 21:44:10 +09:00
onReply : PropTypes . func ,
onFavourite : PropTypes . func ,
onReblog : PropTypes . func ,
onDelete : PropTypes . func ,
2018-04-10 00:09:11 +09:00
onDirect : PropTypes . func ,
onMention : PropTypes . func ,
2022-12-01 01:25:36 +09:00
onReactionAdd : PropTypes . func ,
onReactionRemove : PropTypes . func ,
2017-08-25 08:41:18 +09:00
onPin : PropTypes . func ,
2017-05-12 21:44:10 +09:00
onOpenMedia : PropTypes . func ,
onOpenVideo : PropTypes . func ,
onBlock : PropTypes . func ,
2022-08-25 11:27:47 +09:00
onAddFilter : PropTypes . func ,
2017-09-02 04:30:13 +09:00
onEmbed : PropTypes . func ,
2017-08-08 03:32:03 +09:00
onHeightChange : PropTypes . func ,
2018-03-11 17:52:59 +09:00
onToggleHidden : PropTypes . func ,
Summary: fix slowness due to layout thrashing when reloading a large … (#12661)
* Summary: fix slowness due to layout thrashing when reloading a large set of status updates
in order to limit the maximum size of a status in a list view (e.g. the home timeline), so as to avoid having to scroll all the way through an abnormally large status update (see https://github.com/tootsuite/mastodon/pull/8205), the following steps are taken:
•the element containing the status is rendered in the browser
•its height is calculated, to determine if it exceeds the maximum height threshold.
Unfortunately for performance, these steps are carried out in the componentDidMount(/Update) method, which also performs style modifications on the element. The combination of height request and style modification during javascript evaluation in the browser leads to layout-thrashing, where the elements are repeatedly re-laid-out (see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing & https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers).
The solution implemented here is to memoize the collapsed state in Redux the first time the status is seen (e.g. when fetched as part of a small batch, to populate the home timeline) , so that on subsequent re-renders, the value can be queried, rather than recalculated. This strategy is derived from https://github.com/tootsuite/mastodon/pull/4439 & https://github.com/tootsuite/mastodon/pull/4909, and should resolve https://github.com/tootsuite/mastodon/issues/12455.
Andrew Lin (https://github.com/onethreeseven) is thanked for his assistance in root cause analysis and solution brainstorming
* remove getSnapshotBeforeUpdate from status
* remove componentWillUnmount from status
* persist last-intersected status update and restore when ScrollableList is restored
e.g. when navigating from home-timeline to a status conversational thread and <Back again
* cache currently-viewing status id to avoid calling redux with identical value
* refactor collapse toggle to pass explicit boolean
2019-12-29 13:39:48 +09:00
onToggleCollapsed : PropTypes . func ,
2022-09-24 06:00:12 +09:00
onTranslate : PropTypes . func ,
2022-10-07 17:14:31 +09:00
onInteractionModal : PropTypes . func ,
2017-05-21 00:31:47 +09:00
muted : PropTypes . bool ,
2017-08-29 05:23:44 +09:00
hidden : PropTypes . bool ,
2018-10-20 09:23:58 +09:00
unread : PropTypes . bool ,
2017-10-06 08:07:59 +09:00
onMoveUp : PropTypes . func ,
onMoveDown : PropTypes . func ,
2018-11-09 05:08:57 +09:00
showThread : PropTypes . bool ,
2019-02-11 21:19:59 +09:00
getScrollPosition : PropTypes . func ,
updateScrollBottom : PropTypes . func ,
cacheMediaWidth : PropTypes . func ,
cachedMediaWidth : PropTypes . number ,
2020-07-09 22:09:19 +09:00
scrollKey : PropTypes . string ,
2020-09-28 20:29:43 +09:00
deployPictureInPicture : PropTypes . func ,
2022-12-01 01:25:36 +09:00
emojiMap : ImmutablePropTypes . map . isRequired ,
2020-12-08 03:36:36 +09:00
pictureInPicture : ImmutablePropTypes . contains ( {
2020-11-16 13:16:39 +09:00
inUse : PropTypes . bool ,
available : PropTypes . bool ,
} ) ,
2017-05-12 21:44:10 +09:00
} ;
2017-05-26 21:05:52 +09:00
// Avoid checking props that are functions (and whose equality will always
// evaluate to false. See react-immutable-pure-component for usage.
updateOnProps = [
'status' ,
'account' ,
'muted' ,
2017-08-29 05:23:44 +09:00
'hidden' ,
2020-09-27 03:57:07 +09:00
'unread' ,
2020-11-16 13:16:39 +09:00
'pictureInPicture' ,
2019-01-17 03:47:46 +09:00
] ;
2017-05-26 21:05:52 +09:00
2019-05-26 06:20:51 +09:00
state = {
2019-05-26 20:48:16 +09:00
showMedia : defaultMediaVisibility ( this . props . status ) ,
2019-05-29 23:33:15 +09:00
statusId : undefined ,
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
forceFilter : undefined ,
2019-05-26 06:20:51 +09:00
} ;
2019-05-29 23:33:15 +09:00
static getDerivedStateFromProps ( nextProps , prevState ) {
if ( nextProps . status && nextProps . status . get ( 'id' ) !== prevState . statusId ) {
return {
showMedia : defaultMediaVisibility ( nextProps . status ) ,
statusId : nextProps . status . get ( 'id' ) ,
} ;
} else {
return null ;
2019-05-26 20:48:16 +09:00
}
}
2019-05-26 06:20:51 +09:00
handleToggleMediaVisibility = ( ) => {
this . setState ( { showMedia : ! this . state . showMedia } ) ;
2023-01-30 09:45:35 +09:00
} ;
2019-05-26 06:20:51 +09:00
2021-09-26 12:46:13 +09:00
handleClick = e => {
if ( e && ( e . button !== 0 || e . ctrlKey || e . metaKey ) ) {
2018-10-20 09:23:58 +09:00
return ;
}
2021-09-26 12:46:13 +09:00
if ( e ) {
e . preventDefault ( ) ;
2017-07-11 22:27:59 +09:00
}
2021-09-26 12:46:13 +09:00
this . handleHotkeyOpen ( ) ;
2023-01-30 09:45:35 +09:00
} ;
2016-09-16 07:21:51 +09:00
2021-11-27 06:04:09 +09:00
handlePrependAccountClick = e => {
this . handleAccountClick ( e , false ) ;
2023-01-30 09:45:35 +09:00
} ;
2021-11-27 06:04:09 +09:00
handleAccountClick = ( e , proper = true ) => {
2021-09-26 12:46:13 +09:00
if ( e && ( e . button !== 0 || e . ctrlKey || e . metaKey ) ) {
2019-06-11 02:27:10 +09:00
return ;
}
2021-09-26 12:46:13 +09:00
if ( e ) {
2016-09-16 07:21:51 +09:00
e . preventDefault ( ) ;
2023-02-20 16:11:23 +09:00
e . stopPropagation ( ) ;
2016-09-16 07:21:51 +09:00
}
2021-09-26 12:46:13 +09:00
2021-11-27 06:04:09 +09:00
this . _openProfile ( proper ) ;
2023-01-30 09:45:35 +09:00
} ;
2016-09-13 09:24:40 +09:00
2017-06-14 03:46:21 +09:00
handleExpandedToggle = ( ) => {
2018-03-11 17:52:59 +09:00
this . props . onToggleHidden ( this . _properStatus ( ) ) ;
2023-01-30 09:45:35 +09:00
} ;
Summary: fix slowness due to layout thrashing when reloading a large … (#12661)
* Summary: fix slowness due to layout thrashing when reloading a large set of status updates
in order to limit the maximum size of a status in a list view (e.g. the home timeline), so as to avoid having to scroll all the way through an abnormally large status update (see https://github.com/tootsuite/mastodon/pull/8205), the following steps are taken:
•the element containing the status is rendered in the browser
•its height is calculated, to determine if it exceeds the maximum height threshold.
Unfortunately for performance, these steps are carried out in the componentDidMount(/Update) method, which also performs style modifications on the element. The combination of height request and style modification during javascript evaluation in the browser leads to layout-thrashing, where the elements are repeatedly re-laid-out (see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing & https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers).
The solution implemented here is to memoize the collapsed state in Redux the first time the status is seen (e.g. when fetched as part of a small batch, to populate the home timeline) , so that on subsequent re-renders, the value can be queried, rather than recalculated. This strategy is derived from https://github.com/tootsuite/mastodon/pull/4439 & https://github.com/tootsuite/mastodon/pull/4909, and should resolve https://github.com/tootsuite/mastodon/issues/12455.
Andrew Lin (https://github.com/onethreeseven) is thanked for his assistance in root cause analysis and solution brainstorming
* remove getSnapshotBeforeUpdate from status
* remove componentWillUnmount from status
* persist last-intersected status update and restore when ScrollableList is restored
e.g. when navigating from home-timeline to a status conversational thread and <Back again
* cache currently-viewing status id to avoid calling redux with identical value
* refactor collapse toggle to pass explicit boolean
2019-12-29 13:39:48 +09:00
handleCollapsedToggle = isCollapsed => {
this . props . onToggleCollapsed ( this . _properStatus ( ) , isCollapsed ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-06-14 03:46:21 +09:00
2022-09-24 06:00:12 +09:00
handleTranslate = ( ) => {
this . props . onTranslate ( this . _properStatus ( ) ) ;
2023-01-30 09:45:35 +09:00
} ;
2022-09-24 06:00:12 +09:00
2017-07-08 07:06:02 +09:00
renderLoadingMediaGallery ( ) {
2019-08-24 05:38:02 +09:00
return < div className = 'media-gallery' style = { { height : '110px' } } / > ;
2017-07-08 07:06:02 +09:00
}
renderLoadingVideoPlayer ( ) {
2019-08-24 05:38:02 +09:00
return < div className = 'video-player' style = { { height : '110px' } } / > ;
}
renderLoadingAudioPlayer ( ) {
return < div className = 'audio-player' style = { { height : '110px' } } / > ;
2017-07-08 07:06:02 +09:00
}
2020-12-07 12:29:37 +09:00
handleOpenVideo = ( options ) => {
const status = this . _properStatus ( ) ;
this . props . onOpenVideo ( status . get ( 'id' ) , status . getIn ( [ 'media_attachments' , 0 ] ) , options ) ;
2023-01-30 09:45:35 +09:00
} ;
2020-11-27 11:24:11 +09:00
handleOpenMedia = ( media , index ) => {
this . props . onOpenMedia ( this . _properStatus ( ) . get ( 'id' ) , media , index ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
2019-11-30 01:02:36 +09:00
handleHotkeyOpenMedia = e => {
2019-12-05 08:50:51 +09:00
const { onOpenMedia , onOpenVideo } = this . props ;
2020-12-09 08:24:13 +09:00
const status = this . _properStatus ( ) ;
2019-11-30 01:02:36 +09:00
e . preventDefault ( ) ;
if ( status . get ( 'media_attachments' ) . size > 0 ) {
2020-11-27 11:24:11 +09:00
if ( status . getIn ( [ 'media_attachments' , 0 , 'type' ] ) === 'video' ) {
2020-12-09 08:24:13 +09:00
onOpenVideo ( status . get ( 'id' ) , status . getIn ( [ 'media_attachments' , 0 ] ) , { startTime : 0 } ) ;
2019-11-30 01:02:36 +09:00
} else {
2020-12-09 08:24:13 +09:00
onOpenMedia ( status . get ( 'id' ) , status . get ( 'media_attachments' ) , 0 ) ;
2019-11-30 01:02:36 +09:00
}
}
2023-01-30 09:45:35 +09:00
} ;
2019-11-30 01:02:36 +09:00
2020-09-28 20:29:43 +09:00
handleDeployPictureInPicture = ( type , mediaProps ) => {
const { deployPictureInPicture } = this . props ;
const status = this . _properStatus ( ) ;
deployPictureInPicture ( status , type , mediaProps ) ;
2023-01-30 09:45:35 +09:00
} ;
2020-09-28 20:29:43 +09:00
2017-10-06 08:07:59 +09:00
handleHotkeyReply = e => {
e . preventDefault ( ) ;
this . props . onReply ( this . _properStatus ( ) , this . context . router . history ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
handleHotkeyFavourite = ( ) => {
this . props . onFavourite ( this . _properStatus ( ) ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
handleHotkeyBoost = e => {
this . props . onReblog ( this . _properStatus ( ) , e ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
handleHotkeyMention = e => {
e . preventDefault ( ) ;
this . props . onMention ( this . _properStatus ( ) . get ( 'account' ) , this . context . router . history ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
handleHotkeyOpen = ( ) => {
2021-09-26 12:46:13 +09:00
if ( this . props . onClick ) {
this . props . onClick ( ) ;
return ;
}
const { router } = this . context ;
const status = this . _properStatus ( ) ;
if ( ! router ) {
return ;
}
router . history . push ( ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } / ${ status . get ( 'id' ) } ` ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
handleHotkeyOpenProfile = ( ) => {
2021-11-27 06:04:09 +09:00
this . _openProfile ( ) ;
2023-01-30 09:45:35 +09:00
} ;
2021-11-27 06:04:09 +09:00
_openProfile = ( proper = true ) => {
2021-09-26 12:46:13 +09:00
const { router } = this . context ;
2021-11-27 06:04:09 +09:00
const status = proper ? this . _properStatus ( ) : this . props . status ;
2021-09-26 12:46:13 +09:00
if ( ! router ) {
return ;
}
router . history . push ( ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } ` ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
2018-04-21 01:14:21 +09:00
handleHotkeyMoveUp = e => {
this . props . onMoveUp ( this . props . status . get ( 'id' ) , e . target . getAttribute ( 'data-featured' ) ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
2018-04-21 01:14:21 +09:00
handleHotkeyMoveDown = e => {
this . props . onMoveDown ( this . props . status . get ( 'id' ) , e . target . getAttribute ( 'data-featured' ) ) ;
2023-01-30 09:45:35 +09:00
} ;
2017-10-06 08:07:59 +09:00
2018-04-18 10:33:59 +09:00
handleHotkeyToggleHidden = ( ) => {
this . props . onToggleHidden ( this . _properStatus ( ) ) ;
2023-01-30 09:45:35 +09:00
} ;
2018-04-18 10:33:59 +09:00
2019-05-26 06:20:51 +09:00
handleHotkeyToggleSensitive = ( ) => {
this . handleToggleMediaVisibility ( ) ;
2023-01-30 09:45:35 +09:00
} ;
2019-05-26 06:20:51 +09:00
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
handleUnfilterClick = e => {
this . setState ( { forceFilter : false } ) ;
e . preventDefault ( ) ;
2023-01-30 09:45:35 +09:00
} ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
handleFilterClick = ( ) => {
this . setState ( { forceFilter : true } ) ;
2023-01-30 09:45:35 +09:00
} ;
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
2017-10-06 08:07:59 +09:00
_properStatus ( ) {
const { status } = this . props ;
if ( status . get ( 'reblog' , null ) !== null && typeof status . get ( 'reblog' ) === 'object' ) {
return status . get ( 'reblog' ) ;
} else {
return status ;
}
2017-09-14 10:39:10 +09:00
}
2019-02-11 21:19:59 +09:00
handleRef = c => {
this . node = c ;
2023-01-30 09:45:35 +09:00
} ;
2019-02-11 21:19:59 +09:00
2016-08-25 04:08:00 +09:00
render ( ) {
2023-04-24 15:07:03 +09:00
const { intl , hidden , featured , unread , showThread , scrollKey , pictureInPicture , previousId , nextInReplyToId , rootId } = this . props ;
2016-09-06 03:38:31 +09:00
2017-10-06 08:07:59 +09:00
let { status , account , ... other } = this . props ;
2016-10-25 18:13:16 +09:00
if ( status === null ) {
2017-05-26 21:07:48 +09:00
return null ;
2017-05-25 00:55:00 +09:00
}
2019-08-20 02:00:33 +09:00
const handlers = this . props . muted ? { } : {
reply : this . handleHotkeyReply ,
favourite : this . handleHotkeyFavourite ,
boost : this . handleHotkeyBoost ,
mention : this . handleHotkeyMention ,
open : this . handleHotkeyOpen ,
openProfile : this . handleHotkeyOpenProfile ,
moveUp : this . handleHotkeyMoveUp ,
moveDown : this . handleHotkeyMoveDown ,
toggleHidden : this . handleHotkeyToggleHidden ,
toggleSensitive : this . handleHotkeyToggleSensitive ,
2019-11-30 01:02:36 +09:00
openMedia : this . handleHotkeyOpenMedia ,
2019-08-20 02:00:33 +09:00
} ;
2023-04-24 15:07:03 +09:00
let media , statusAvatar , prepend , rebloggedByText ;
2017-08-29 05:23:44 +09:00
if ( hidden ) {
2017-05-25 00:55:00 +09:00
return (
2019-08-20 02:00:33 +09:00
< HotKeys handlers = { handlers } >
2023-04-04 23:33:44 +09:00
< div ref = { this . handleRef } className = { classNames ( 'status__wrapper' , { focusable : ! this . props . muted } ) } tabIndex = { 0 } >
2021-07-23 09:53:17 +09:00
< span > { status . getIn ( [ 'account' , 'display_name' ] ) || status . getIn ( [ 'account' , 'username' ] ) } < / span >
< span > { status . get ( 'content' ) } < / span >
2019-08-20 02:00:33 +09:00
< / div >
< / HotKeys >
2017-05-25 00:55:00 +09:00
) ;
2016-10-25 18:13:16 +09:00
}
2023-04-24 15:07:03 +09:00
const connectUp = previousId && previousId === status . get ( 'in_reply_to_id' ) ;
const connectToRoot = rootId && rootId === status . get ( 'in_reply_to_id' ) ;
const connectReply = nextInReplyToId && nextInReplyToId === status . get ( 'id' ) ;
2022-06-30 16:51:55 +09:00
const matchedFilters = status . get ( 'matched_filters' ) ;
2023-04-24 15:07:03 +09:00
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
if ( this . state . forceFilter === undefined ? matchedFilters : this . state . forceFilter ) {
2018-06-29 22:34:36 +09:00
const minHandlers = this . props . muted ? { } : {
moveUp : this . handleHotkeyMoveUp ,
moveDown : this . handleHotkeyMoveDown ,
} ;
return (
< HotKeys handlers = { minHandlers } >
2023-04-04 23:33:44 +09:00
< div className = 'status__wrapper status__wrapper--filtered focusable' tabIndex = { 0 } ref = { this . handleRef } >
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
< FormattedMessage id = 'status.filtered' defaultMessage = 'Filtered' / > : { matchedFilters . join ( ', ' ) } .
{ ' ' }
< button className = 'status__wrapper--filtered__button' onClick = { this . handleUnfilterClick } >
< FormattedMessage id = 'status.show_filter_reason' defaultMessage = 'Show anyway' / >
< / button >
2018-06-29 22:34:36 +09:00
< / div >
< / HotKeys >
) ;
}
2018-03-04 17:19:11 +09:00
if ( featured ) {
prepend = (
< div className = 'status__prepend' >
2019-02-01 08:14:05 +09:00
< div className = 'status__prepend-icon-wrapper' > < Icon id = 'thumb-tack' className = 'status__prepend-icon' fixedWidth / > < / div >
2022-04-29 07:24:31 +09:00
< FormattedMessage id = 'status.pinned' defaultMessage = 'Pinned post' / >
2018-03-04 17:19:11 +09:00
< / div >
) ;
} else if ( status . get ( 'reblog' , null ) !== null && typeof status . get ( 'reblog' ) === 'object' ) {
2017-08-08 03:32:03 +09:00
const display _name _html = { _ _html : status . getIn ( [ 'account' , 'display_name_html' ] ) } ;
2016-11-19 08:28:42 +09:00
2017-10-06 08:07:59 +09:00
prepend = (
< div className = 'status__prepend' >
2019-02-01 08:14:05 +09:00
< div className = 'status__prepend-icon-wrapper' > < Icon id = 'retweet' className = 'status__prepend-icon' fixedWidth / > < / div >
2022-11-14 05:10:20 +09:00
< FormattedMessage id = 'status.reblogged_by' defaultMessage = '{name} boosted' values = { { name : < a onClick = { this . handlePrependAccountClick } data - id = { status . getIn ( [ 'account' , 'id' ] ) } href = { ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } ` } className = 'status__display-name muted' > < bdi > < strong dangerouslySetInnerHTML = { display _name _html } / > < / bdi > < / a > } } / >
2017-08-29 05:23:44 +09:00
< / div >
2016-09-01 21:12:11 +09:00
) ;
2017-10-06 08:07:59 +09:00
2018-08-24 03:56:57 +09:00
rebloggedByText = intl . formatMessage ( { id : 'status.reblogged_by' , defaultMessage : '{name} boosted' } , { name : status . getIn ( [ 'account' , 'acct' ] ) } ) ;
2017-10-06 08:07:59 +09:00
account = status . get ( 'account' ) ;
status = status . get ( 'reblog' ) ;
2023-03-30 22:16:20 +09:00
} else if ( status . get ( 'visibility' ) === 'direct' ) {
prepend = (
< div className = 'status__prepend' >
< div className = 'status__prepend-icon-wrapper' > < Icon id = 'at' className = 'status__prepend-icon' fixedWidth / > < / div >
< FormattedMessage id = 'status.direct_indicator' defaultMessage = 'Private mention' / >
< / div >
) ;
2022-10-26 02:02:21 +09:00
} else if ( showThread && status . get ( 'in_reply_to_id' ) && status . get ( 'in_reply_to_account_id' ) === status . getIn ( [ 'account' , 'id' ] ) ) {
const display _name _html = { _ _html : status . getIn ( [ 'account' , 'display_name_html' ] ) } ;
prepend = (
< div className = 'status__prepend' >
< div className = 'status__prepend-icon-wrapper' > < Icon id = 'reply' className = 'status__prepend-icon' fixedWidth / > < / div >
2022-11-14 05:10:20 +09:00
< FormattedMessage id = 'status.replied_to' defaultMessage = 'Replied to {name}' values = { { name : < a onClick = { this . handlePrependAccountClick } data - id = { status . getIn ( [ 'account' , 'id' ] ) } href = { ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } ` } className = 'status__display-name muted' > < bdi > < strong dangerouslySetInnerHTML = { display _name _html } / > < / bdi > < / a > } } / >
2022-10-26 02:02:21 +09:00
< / div >
) ;
2016-09-01 21:12:11 +09:00
}
2016-08-25 00:56:44 +09:00
2020-12-08 03:36:36 +09:00
if ( pictureInPicture . get ( 'inUse' ) ) {
2023-05-02 20:58:48 +09:00
media = < PictureInPicturePlaceholder / > ;
2020-09-28 20:29:43 +09:00
} else if ( status . get ( 'media_attachments' ) . size > 0 ) {
2019-04-27 10:24:09 +09:00
if ( this . props . muted ) {
2018-03-08 12:54:26 +09:00
media = (
< AttachmentList
compact
media = { status . get ( 'media_attachments' ) }
/ >
) ;
2019-08-24 05:38:02 +09:00
} else if ( status . getIn ( [ 'media_attachments' , 0 , 'type' ] ) === 'audio' ) {
const attachment = status . getIn ( [ 'media_attachments' , 0 ] ) ;
media = (
< Bundle fetchComponent = { Audio } loading = { this . renderLoadingAudioPlayer } >
{ Component => (
< Component
src = { attachment . get ( 'url' ) }
alt = { attachment . get ( 'description' ) }
2023-02-27 04:13:27 +09:00
lang = { status . get ( 'language' ) }
2020-06-29 20:56:55 +09:00
poster = { attachment . get ( 'preview_url' ) || status . getIn ( [ 'account' , 'avatar_static' ] ) }
2020-07-06 01:28:25 +09:00
backgroundColor = { attachment . getIn ( [ 'meta' , 'colors' , 'background' ] ) }
foregroundColor = { attachment . getIn ( [ 'meta' , 'colors' , 'foreground' ] ) }
accentColor = { attachment . getIn ( [ 'meta' , 'colors' , 'accent' ] ) }
2019-08-24 05:38:02 +09:00
duration = { attachment . getIn ( [ 'meta' , 'original' , 'duration' ] , 0 ) }
2020-06-21 09:27:19 +09:00
width = { this . props . cachedMediaWidth }
2020-06-23 19:20:14 +09:00
height = { 110 }
2020-06-21 09:27:19 +09:00
cacheWidth = { this . props . cacheMediaWidth }
2020-12-08 03:36:36 +09:00
deployPictureInPicture = { pictureInPicture . get ( 'available' ) ? this . handleDeployPictureInPicture : undefined }
2022-08-13 22:39:05 +09:00
sensitive = { status . get ( 'sensitive' ) }
blurhash = { attachment . get ( 'blurhash' ) }
visible = { this . state . showMedia }
onToggleVisibility = { this . handleToggleMediaVisibility }
2019-08-24 05:38:02 +09:00
/ >
) }
< / Bundle >
) ;
} else if ( status . getIn ( [ 'media_attachments' , 0 , 'type' ] ) === 'video' ) {
2019-06-20 06:42:38 +09:00
const attachment = status . getIn ( [ 'media_attachments' , 0 ] ) ;
2017-09-14 10:39:10 +09:00
2017-07-08 07:06:02 +09:00
media = (
2017-09-14 10:39:10 +09:00
< Bundle fetchComponent = { Video } loading = { this . renderLoadingVideoPlayer } >
2018-01-18 00:57:15 +09:00
{ Component => (
< Component
2019-06-20 06:42:38 +09:00
preview = { attachment . get ( 'preview_url' ) }
2020-11-22 07:19:04 +09:00
frameRate = { attachment . getIn ( [ 'meta' , 'original' , 'frame_rate' ] ) }
2019-06-20 06:42:38 +09:00
blurhash = { attachment . get ( 'blurhash' ) }
src = { attachment . get ( 'url' ) }
alt = { attachment . get ( 'description' ) }
2023-02-27 04:13:27 +09:00
lang = { status . get ( 'language' ) }
2018-03-02 15:00:04 +09:00
inline
2018-01-18 00:57:15 +09:00
sensitive = { status . get ( 'sensitive' ) }
onOpenVideo = { this . handleOpenVideo }
2020-12-08 03:36:36 +09:00
deployPictureInPicture = { pictureInPicture . get ( 'available' ) ? this . handleDeployPictureInPicture : undefined }
2019-05-26 06:20:51 +09:00
visible = { this . state . showMedia }
onToggleVisibility = { this . handleToggleMediaVisibility }
2018-01-18 00:57:15 +09:00
/ >
) }
2017-07-08 07:06:02 +09:00
< / Bundle >
) ;
2016-09-18 01:05:02 +09:00
} else {
2017-07-08 07:06:02 +09:00
media = (
2018-05-08 20:33:09 +09:00
< Bundle fetchComponent = { MediaGallery } loading = { this . renderLoadingMediaGallery } >
2019-02-11 21:19:59 +09:00
{ Component => (
< Component
media = { status . get ( 'media_attachments' ) }
2023-02-27 04:13:27 +09:00
lang = { status . get ( 'language' ) }
2019-02-11 21:19:59 +09:00
sensitive = { status . get ( 'sensitive' ) }
height = { 110 }
2020-11-27 11:24:11 +09:00
onOpenMedia = { this . handleOpenMedia }
2019-02-11 21:19:59 +09:00
cacheWidth = { this . props . cacheMediaWidth }
defaultWidth = { this . props . cachedMediaWidth }
2019-05-26 06:20:51 +09:00
visible = { this . state . showMedia }
onToggleVisibility = { this . handleToggleMediaVisibility }
2019-02-11 21:19:59 +09:00
/ >
) }
2017-07-08 07:06:02 +09:00
< / Bundle >
) ;
2016-09-18 01:05:02 +09:00
}
2022-11-11 03:36:12 +09:00
} else if ( status . get ( 'spoiler_text' ) . length === 0 && status . get ( 'card' ) && ! this . props . muted ) {
2018-10-28 14:35:03 +09:00
media = (
< Card
2020-12-08 20:07:54 +09:00
onOpenMedia = { this . handleOpenMedia }
2018-10-28 14:35:03 +09:00
card = { status . get ( 'card' ) }
compact
2020-06-07 00:41:56 +09:00
sensitive = { status . get ( 'sensitive' ) }
2018-10-28 14:35:03 +09:00
/ >
) ;
2016-09-06 03:38:31 +09:00
}
2022-05-31 00:10:13 +09:00
if ( account === undefined || account === null ) {
2022-10-26 02:02:21 +09:00
statusAvatar = < Avatar account = { status . get ( 'account' ) } size = { 46 } / > ;
2018-10-20 09:23:58 +09:00
} else {
2017-08-08 02:44:55 +09:00
statusAvatar = < AvatarOverlay account = { status . get ( 'account' ) } friend = { account } / > ;
2017-05-03 18:43:37 +09:00
}
2020-06-26 05:43:59 +09:00
const visibilityIconInfo = {
'public' : { icon : 'globe' , text : intl . formatMessage ( messages . public _short ) } ,
'unlisted' : { icon : 'unlock' , text : intl . formatMessage ( messages . unlisted _short ) } ,
'private' : { icon : 'lock' , text : intl . formatMessage ( messages . private _short ) } ,
2022-05-06 07:41:56 +09:00
'direct' : { icon : 'at' , text : intl . formatMessage ( messages . direct _short ) } ,
2020-06-26 05:43:59 +09:00
} ;
const visibilityIcon = visibilityIconInfo [ status . get ( 'visibility' ) ] ;
2016-08-25 00:56:44 +09:00
return (
2017-10-06 08:07:59 +09:00
< HotKeys handlers = { handlers } >
2020-09-27 03:57:07 +09:00
< div className = { classNames ( 'status__wrapper' , ` status__wrapper- ${ status . get ( 'visibility' ) } ` , { 'status__wrapper-reply' : ! ! status . get ( 'in_reply_to_id' ) , unread , focusable : ! this . props . muted } ) } tabIndex = { this . props . muted ? null : 0 } data - featured = { featured ? 'true' : null } aria - label = { textForScreenReader ( intl , status , rebloggedByText ) } ref = { this . handleRef } >
2017-10-06 08:07:59 +09:00
{ prepend }
2016-08-25 04:08:00 +09:00
2023-04-24 15:07:03 +09:00
< div className = { classNames ( 'status' , ` status- ${ status . get ( 'visibility' ) } ` , { 'status-reply' : ! ! status . get ( 'in_reply_to_id' ) , 'status--in-thread' : ! ! rootId , 'status--first-in-thread' : previousId && ( ! connectUp || connectToRoot ) , muted : this . props . muted } ) } data - id = { status . get ( 'id' ) } >
{ ( connectReply || connectUp || connectToRoot ) && < div className = { classNames ( 'status__line' , { 'status__line--full' : connectReply , 'status__line--first' : ! status . get ( 'in_reply_to_id' ) && ! connectToRoot } ) } / > }
2023-04-24 05:24:53 +09:00
{ /* eslint-disable-next-line jsx-a11y/no-static-element-interactions */ }
2023-02-20 16:11:23 +09:00
< div onClick = { this . handleClick } className = 'status__info' >
< a href = { ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } / ${ status . get ( 'id' ) } ` } className = 'status__relative-time' target = '_blank' rel = 'noopener noreferrer' >
2020-10-27 11:00:47 +09:00
< span className = 'status__visibility-icon' > < Icon id = { visibilityIcon . icon } title = { visibilityIcon . text } / > < / span >
2022-01-20 06:37:27 +09:00
< RelativeTimestamp timestamp = { status . get ( 'created_at' ) } / > { status . get ( 'edited_at' ) && < abbr title = { intl . formatMessage ( messages . edited , { date : intl . formatDate ( status . get ( 'edited_at' ) , { hour12 : false , year : 'numeric' , month : 'short' , day : '2-digit' , hour : '2-digit' , minute : '2-digit' } ) } ) } > * < / abbr > }
2020-10-27 11:00:47 +09:00
< / a >
2016-08-25 04:08:00 +09:00
2022-11-14 05:10:20 +09:00
< a onClick = { this . handleAccountClick } href = { ` /@ ${ status . getIn ( [ 'account' , 'acct' ] ) } ` } title = { status . getIn ( [ 'account' , 'acct' ] ) } className = 'status__display-name' target = '_blank' rel = 'noopener noreferrer' >
2017-10-06 08:07:59 +09:00
< div className = 'status__avatar' >
{ statusAvatar }
< / div >
2016-09-01 05:58:10 +09:00
2022-05-31 00:10:13 +09:00
< DisplayName account = { status . get ( 'account' ) } / >
2017-10-06 08:07:59 +09:00
< / a >
< / div >
2022-09-24 06:00:12 +09:00
< StatusContent
status = { status }
onClick = { this . handleClick }
expanded = { ! status . get ( 'hidden' ) }
onExpandedToggle = { this . handleExpandedToggle }
onTranslate = { this . handleTranslate }
2023-04-14 18:01:23 +09:00
collapsible
2022-09-24 06:00:12 +09:00
onCollapsedToggle = { this . handleCollapsedToggle }
/ >
2016-08-25 04:08:00 +09:00
2017-10-06 08:07:59 +09:00
{ media }
2016-09-06 03:38:31 +09:00
2022-12-01 01:25:36 +09:00
< StatusReactions
statusId = { status . get ( 'id' ) }
reactions = { status . get ( 'reactions' ) }
numVisible = { visibleReactions }
addReaction = { this . props . onReactionAdd }
removeReaction = { this . props . onReactionRemove }
2022-12-04 21:33:47 +09:00
canReact = { this . context . identity . signedIn }
2022-12-01 01:25:36 +09:00
/ >
2022-08-25 11:37:40 +09:00
< StatusActionBar scrollKey = { scrollKey } status = { status } account = { account } onFilter = { matchedFilters ? this . handleFilterClick : null } { ...other } / >
2017-10-06 08:07:59 +09:00
< / div >
< / div >
< / HotKeys >
2016-08-25 00:56:44 +09:00
) ;
}
2016-08-31 23:15:12 +09:00
2017-04-22 03:05:35 +09:00
}
2023-03-24 11:17:53 +09:00
export default injectIntl ( Status ) ;