fedibird-fe/app/serializers/initial_state_serializer.rb

136 lines
7.8 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
class InitialStateSerializer < ActiveModel::Serializer
2022-08-23 05:14:23 +00:00
attributes :meta, :compose, :search, :accounts, :lists,
2022-03-17 14:25:16 +00:00
:media_attachments, :status_references, :settings
has_one :push_subscription, serializer: REST::WebPushSubscriptionSerializer
def meta
store = {
streaming_api_base_url: Rails.configuration.x.streaming_api_base_url,
access_token: object.token,
locale: I18n.locale,
domain: Rails.configuration.x.local_domain,
title: instance_presenter.site_title,
Change IDs to strings rather than numbers in API JSON output (#5019) * Fix JavaScript interface with long IDs Somewhat predictably, the JS interface handled IDs as numbers, which in JS are IEEE double-precision floats. This loses some precision when working with numbers as large as those generated by the new ID scheme, so we instead handle them here as strings. This is relatively simple, and doesn't appear to have caused any problems, but should definitely be tested more thoroughly than the built-in tests. Several days of use appear to support this working properly. BREAKING CHANGE: The major(!) change here is that IDs are now returned as strings by the REST endpoints, rather than as integers. In practice, relatively few changes were required to make the existing JS UI work with this change, but it will likely hit API clients pretty hard: it's an entirely different type to consume. (The one API client I tested, Tusky, handles this with no problems, however.) Twitter ran into this issue when introducing Snowflake IDs, and decided to instead introduce an `id_str` field in JSON responses. I have opted to *not* do that, and instead force all IDs to 64-bit integers represented by strings in one go. (I believe Twitter exacerbated their problem by rolling out the changes three times: once for statuses, once for DMs, and once for user IDs, as well as by leaving an integer ID value in JSON. As they said, "If you’re using the `id` field with JSON in a Javascript-related language, there is a very high likelihood that the integers will be silently munged by Javascript interpreters. In most cases, this will result in behavior such as being unable to load or delete a specific direct message, because the ID you're sending to the API is different than the actual identifier associated with the message." [1]) However, given that this is a significant change for API users, alternatives or a transition time may be appropriate. 1: https://blog.twitter.com/developer/en_us/a/2011/direct-messages-going-snowflake-on-sep-30-2011.html * Additional fixes for stringified IDs in JSON These should be the last two. These were identified using eslint to try to identify any plain casts to JavaScript numbers. (Some such casts are legitimate, but these were not.) Adding the following to .eslintrc.yml will identify casts to numbers: ~~~ no-restricted-syntax: - warn - selector: UnaryExpression[operator='+'] > :not(Literal) message: Avoid the use of unary + - selector: CallExpression[callee.name='Number'] message: Casting with Number() may coerce string IDs to numbers ~~~ The remaining three casts appear legitimate: two casts to array indices, one in a server to turn an environment variable into a number. * Back out RelationshipsController Change This was made to make a test a bit less flakey, but has nothing to do with this branch. * Change internal streaming payloads to stringified IDs as well Per https://github.com/tootsuite/mastodon/pull/5019#issuecomment-330736452 we need these changes to send deleted status IDs as strings, not integers.
2017-09-20 12:53:48 +00:00
admin: object.admin&.id&.to_s,
search_enabled: Chewy.enabled?,
repository: Mastodon::Version.repository,
source_url: Mastodon::Version.source_url,
version: Mastodon::Version.to_s,
invites_enabled: Setting.min_invite_role == 'user',
2021-06-27 20:31:28 +00:00
limited_federation_mode: Rails.configuration.x.whitelist_mode,
mascot: instance_presenter.mascot&.file&.url,
profile_directory: Setting.profile_directory,
trends: Setting.trends,
}
if object.current_account
store[:me] = object.current_account.id.to_s
store[:unfollow_modal] = object.current_account.user.setting_unfollow_modal
store[:unsubscribe_modal] = object.current_account.user.setting_unsubscribe_modal
store[:boost_modal] = object.current_account.user.setting_boost_modal
store[:delete_modal] = object.current_account.user.setting_delete_modal
store[:auto_play_gif] = object.current_account.user.setting_auto_play_gif
store[:display_media] = object.current_account.user.setting_display_media
store[:expand_spoilers] = object.current_account.user.setting_expand_spoilers
store[:reduce_motion] = object.current_account.user.setting_reduce_motion
store[:disable_swiping] = object.current_account.user.setting_disable_swiping
store[:advanced_layout] = object.current_account.user.setting_advanced_layout
store[:use_blurhash] = object.current_account.user.setting_use_blurhash
store[:use_pending_items] = object.current_account.user.setting_use_pending_items
store[:is_staff] = object.current_account.user.staff?
store[:trends] = Setting.trends && object.current_account.user.setting_trends
store[:crop_images] = object.current_account.user.setting_crop_images
store[:confirm_domain_block] = object.current_account.user.setting_confirm_domain_block
store[:show_follow_button_on_timeline] = object.current_account.user.setting_show_follow_button_on_timeline
store[:show_subscribe_button_on_timeline] = object.current_account.user.setting_show_subscribe_button_on_timeline
2020-03-21 04:25:30 +00:00
store[:show_followed_by] = object.current_account.user.setting_show_followed_by
store[:follow_button_to_list_adder] = object.current_account.user.setting_follow_button_to_list_adder
store[:show_navigation_panel] = object.current_account.user.setting_show_navigation_panel
store[:show_quote_button] = object.current_account.user.setting_show_quote_button
store[:show_bookmark_button] = object.current_account.user.setting_show_bookmark_button
store[:show_target] = object.current_account.user.setting_show_target
store[:place_tab_bar_at_bottom] = object.current_account.user.setting_place_tab_bar_at_bottom
store[:show_tab_bar_label] = object.current_account.user.setting_show_tab_bar_label
2021-04-12 12:43:25 +00:00
store[:enable_limited_timeline] = object.current_account.user.setting_enable_limited_timeline
2021-05-19 05:58:27 +00:00
store[:enable_reaction] = object.current_account.user.setting_enable_reaction
store[:compact_reaction] = object.current_account.user.setting_compact_reaction
store[:show_reply_tree_button] = object.current_account.user.setting_show_reply_tree_button
store[:disable_joke_appearance] = object.current_account.user.setting_disable_joke_appearance
store[:new_features_policy] = object.current_account.user.setting_new_features_policy
2022-02-20 21:32:59 +00:00
store[:theme_instance_ticker] = object.current_account.user.setting_theme_instance_ticker
store[:theme_public] = object.current_account.user.setting_theme_public
2022-03-17 14:25:16 +00:00
store[:enable_status_reference] = object.current_account.user.setting_enable_status_reference
store[:match_visibility_of_references] = object.current_account.user.setting_match_visibility_of_references
store[:post_reference_modal] = object.current_account.user.setting_post_reference_modal
store[:add_reference_modal] = object.current_account.user.setting_add_reference_modal
store[:unselect_reference_modal] = object.current_account.user.setting_unselect_reference_modal
store[:enable_empty_column] = object.current_account.user.setting_enable_empty_column
2022-06-02 06:46:38 +00:00
store[:content_font_size] = object.current_account.user.setting_content_font_size
store[:info_font_size] = object.current_account.user.setting_info_font_size
store[:content_emoji_reaction_size] = object.current_account.user.setting_content_emoji_reaction_size
store[:hide_bot_on_public_timeline] = object.current_account.user.setting_hide_bot_on_public_timeline
2022-08-29 08:22:23 +00:00
store[:confirm_follow_from_bot] = object.current_account.user.setting_confirm_follow_from_bot
store[:show_reload_button] = object.current_account.user.setting_show_reload_button
2022-09-23 12:06:47 +00:00
store[:default_column_width] = object.current_account.user.setting_default_column_width
else
store[:auto_play_gif] = Setting.auto_play_gif
store[:display_media] = Setting.display_media
store[:reduce_motion] = Setting.reduce_motion
store[:use_blurhash] = Setting.use_blurhash
store[:crop_images] = Setting.crop_images
end
store
end
def compose
store = {}
if object.current_account
2022-08-23 05:14:23 +00:00
store[:me] = object.current_account.id.to_s
store[:default_privacy] = object.visibility || object.current_account.user.setting_default_privacy
store[:default_searchability] = object.current_account.searchability
store[:default_sensitive] = object.current_account.user.setting_default_sensitive
end
store[:text] = object.text if object.text
store
end
2022-08-23 05:14:23 +00:00
def search
store = {}
store[:default_searchability] = object.current_account.user.setting_default_search_searchability if object.current_account
store
end
def accounts
store = {}
Change IDs to strings rather than numbers in API JSON output (#5019) * Fix JavaScript interface with long IDs Somewhat predictably, the JS interface handled IDs as numbers, which in JS are IEEE double-precision floats. This loses some precision when working with numbers as large as those generated by the new ID scheme, so we instead handle them here as strings. This is relatively simple, and doesn't appear to have caused any problems, but should definitely be tested more thoroughly than the built-in tests. Several days of use appear to support this working properly. BREAKING CHANGE: The major(!) change here is that IDs are now returned as strings by the REST endpoints, rather than as integers. In practice, relatively few changes were required to make the existing JS UI work with this change, but it will likely hit API clients pretty hard: it's an entirely different type to consume. (The one API client I tested, Tusky, handles this with no problems, however.) Twitter ran into this issue when introducing Snowflake IDs, and decided to instead introduce an `id_str` field in JSON responses. I have opted to *not* do that, and instead force all IDs to 64-bit integers represented by strings in one go. (I believe Twitter exacerbated their problem by rolling out the changes three times: once for statuses, once for DMs, and once for user IDs, as well as by leaving an integer ID value in JSON. As they said, "If you’re using the `id` field with JSON in a Javascript-related language, there is a very high likelihood that the integers will be silently munged by Javascript interpreters. In most cases, this will result in behavior such as being unable to load or delete a specific direct message, because the ID you're sending to the API is different than the actual identifier associated with the message." [1]) However, given that this is a significant change for API users, alternatives or a transition time may be appropriate. 1: https://blog.twitter.com/developer/en_us/a/2011/direct-messages-going-snowflake-on-sep-30-2011.html * Additional fixes for stringified IDs in JSON These should be the last two. These were identified using eslint to try to identify any plain casts to JavaScript numbers. (Some such casts are legitimate, but these were not.) Adding the following to .eslintrc.yml will identify casts to numbers: ~~~ no-restricted-syntax: - warn - selector: UnaryExpression[operator='+'] > :not(Literal) message: Avoid the use of unary + - selector: CallExpression[callee.name='Number'] message: Casting with Number() may coerce string IDs to numbers ~~~ The remaining three casts appear legitimate: two casts to array indices, one in a server to turn an environment variable into a number. * Back out RelationshipsController Change This was made to make a test a bit less flakey, but has nothing to do with this branch. * Change internal streaming payloads to stringified IDs as well Per https://github.com/tootsuite/mastodon/pull/5019#issuecomment-330736452 we need these changes to send deleted status IDs as strings, not integers.
2017-09-20 12:53:48 +00:00
store[object.current_account.id.to_s] = ActiveModelSerializers::SerializableResource.new(object.current_account, serializer: REST::AccountSerializer) if object.current_account
store[object.admin.id.to_s] = ActiveModelSerializers::SerializableResource.new(object.admin, serializer: REST::AccountSerializer) if object.admin
store
end
2021-06-22 03:06:40 +00:00
def lists
store = {}
2021-06-22 03:06:40 +00:00
store = ActiveModelSerializers::SerializableResource.new(object.current_account.owned_lists, each_serializer: REST::ListSerializer) if object.current_account
store
end
def media_attachments
{ accept_content_types: MediaAttachment.supported_file_extensions + MediaAttachment.supported_mime_types }
end
2022-03-17 14:25:16 +00:00
def status_references
{ max_references: StatusReferenceValidator::LIMIT }
end
private
def instance_presenter
@instance_presenter ||= InstancePresenter.new
end
end