Paths

Table of Contentst

-
lib/selectors/
-
selectors/
-
user-selectors.js

[lib] Add userStoreMentionSearchIndex selector
ClosedPublic
Actions

Authored by • patryk on Aug 22 2023, 2:05 AM.

Details

Reviewers

tomek
inka
rohan

Commits

rCOMM02b03698a2c4: [lib] Add userStoreMentionSearchIndex selector

Summary

This diff adds new SearchIndex selector for user mentioning. We need to use SentencePrefixSearchIndex rather than SearchIndex, because SearchIndex catches keywords rather than whole text prefix, so when user would type whole username and then input a space, the tooltip would never close.

Depends on D8900.

Test Plan

Tested later in the stack.

Diff Detail

Repository

rCOMM Comm

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

• patryk created this revision.Aug 22 2023, 2:05 AM

• patryk held this revision as a draft.

Herald added subscribers: tomek, ashoat. · View Herald TranscriptAug 22 2023, 2:05 AM

Harbormaster completed remote builds in B21983: Diff 30185.Aug 22 2023, 2:21 AM

Why when user would type whole username and then input a space, the tooltip would never close?

D8903 will introduce new regex for detecting when typeahead should be shown (it will catch spaces too). Because of that change, the tooltip would never close.

• patryk edited the summary of this revision. (Show Details)Aug 22 2023, 3:33 AM

• patryk added a parent revision: D8900: [lib] Add chat mention SearchIndex selector.

• patryk added a child revision: D8902: [web][native] Use userStoreMentionSearchIndex.Aug 22 2023, 3:35 AM

• patryk added a reviewer: rohan.Aug 22 2023, 5:49 AM

• patryk published this revision for review.Aug 22 2023, 8:38 AM

Rebase

Harbormaster completed remote builds in B22065: Diff 30289.Aug 24 2023, 2:02 PM

D8903 will introduce new regex for detecting when typeahead should be shown (it will catch spaces too). Because of that change, the tooltip would never close.

Wouldn't it close when there are no more matches?
Also this changes the behaviour I believe - before a user named "test_user-hello" could be found by typing in "test", "user" or "hello". If I understand correctly it won't be possible anymore? Can you confirm with @ashoat that this is fine?

inka requested changes to this revision.Aug 29 2023, 5:21 AM

This revision now requires changes to proceed.Aug 29 2023, 5:21 AM

Wouldn't it close when there are no more matches?

It would. But as said in a summary:
because SearchIndex catches keywords rather than whole text prefix, when user would type whole username and then input a space, the tooltip would never close. I wrote an example below.

Also this changes the behaviour I believe - before a user named "test_user-hello" could be found by typing in "test", "user" or "hello". If I understand correctly it won't be possible anymore? Can you confirm with @ashoat that this is fine?

Great catch -> but I think we want to search users by its username prefix (see this). I believe that if we do prefix search on thread names, we should do this also for usernames. Using old SearchIndex might bring new issues:
Consider a chat named 'test user chat' and a user with the username 'user'. Since the SearchIndex.getSearchResults tokenizes the query before performing the lookup, if a user were to type 'test', the username of the user would not appear in the tooltip. However, after typing 'test user', the user would then appear in the tooltip.

D8903 will introduce new regex for detecting when typeahead should be shown (it will catch spaces too). Because of that change, the tooltip would never close.

D8903 was abandoned, does this influence this diff? What does the regex look like now?

I can confirm that we're looking to do only prefix search for @-mentions of chats. We'll continue to do a "full text search" for in the "Search chats" experience as well as the message search experience. But the typeahead is meant to be prefix-only

In D8901#267694, @inka wrote:

D8903 will introduce new regex for detecting when typeahead should be shown (it will catch spaces too). Because of that change, the tooltip would never close.

D8903 was abandoned, does this influence this diff? What does the regex look like now?

D8903 does not influence this diff. You can see the regex here: D8910

inka accepted this revision.Sep 22 2023, 7:20 AM

This revision is now accepted and ready to land.Sep 22 2023, 7:20 AM

Closed by commit rCOMM02b03698a2c4: [lib] Add userStoreMentionSearchIndex selector (authored by • patryk). · Explain WhySep 28 2023, 2:52 AM

This revision was automatically updated to reflect the committed changes.

• patryk added a commit: rCOMM02b03698a2c4: [lib] Add userStoreMentionSearchIndex selector.

Revision Contents
Changeset List

Path

Size

lib/

selectors/

user-selectors.js

34 lines

Diff 30289

View Options

lib/selectors/user-selectors.js

	require File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking")			require File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking")
	require File.join(File.dirname(`node --print "require.resolve('react-native/package.json')"`), "scripts/react_native_pods")			require File.join(File.dirname(`node --print "require.resolve('react-native/package.json')"`), "scripts/react_native_pods")
	require File.join(File.dirname(`node --print "require.resolve('@react-native-community/cli-platform-ios/package.json')"`), "native_modules")			require File.join(File.dirname(`node --print "require.resolve('@react-native-community/cli-platform-ios/package.json')"`), "native_modules")

	platform :ios, '12.0'			platform :ios, '12.0'

	require 'json'			require 'json'
	podfile_properties = JSON.parse(File.read('./Podfile.properties.json')) rescue {}

	target 'Comm' do			def common_comm_target_pods
	pod 'ReactNativeKeyboardTrackingView', :path => '../../node_modules/react-native-keyboard-tracking-view'
	pod 'ReactNativeKeyboardInput', :path => '../../node_modules/react-native-keyboard-input'
	pod 'react-native-ffmpeg/min-lts', :podspec => '../../node_modules/react-native-ffmpeg/react-native-ffmpeg.podspec'
	pod 'react-native-video/VideoCaching', :podspec => '../../node_modules/react-native-video/react-native-video.podspec'
	pod 'SQLCipher-Amalgamation', :path => '../../node_modules/@commapp/sqlcipher-amalgamation'			pod 'SQLCipher-Amalgamation', :path => '../../node_modules/@commapp/sqlcipher-amalgamation'

	pod 'gRPC-C++', :podspec => './pod-patch/.patched/gRPC-C++/1.40.0/gRPC-C++.podspec.json'			pod 'gRPC-C++', :podspec => './pod-patch/.patched/gRPC-C++/1.40.0/gRPC-C++.podspec.json'
	pod 'gRPC-C++/Protobuf', :podspec => './pod-patch/.patched/gRPC-C++/1.40.0/gRPC-C++.podspec.json'			pod 'gRPC-C++/Protobuf', :podspec => './pod-patch/.patched/gRPC-C++/1.40.0/gRPC-C++.podspec.json'
	pod 'gRPC-Core', :podspec => './pod-patch/.patched/gRPC-Core/1.40.0/gRPC-Core.podspec.json'			pod 'gRPC-Core', :podspec => './pod-patch/.patched/gRPC-Core/1.40.0/gRPC-Core.podspec.json'
	pod 'Protobuf-C++', '3.15.8'			pod 'Protobuf-C++', '3.15.8'
				end

				target 'Comm' do
				pod 'ReactNativeKeyboardTrackingView', :path => '../../node_modules/react-native-keyboard-tracking-view'
				pod 'ReactNativeKeyboardInput', :path => '../../node_modules/react-native-keyboard-input'
				pod 'react-native-video/VideoCaching', :podspec => '../../node_modules/react-native-video/react-native-video.podspec'
				pod 'react-native-ffmpeg/min-lts', :podspec => '../../node_modules/react-native-ffmpeg/react-native-ffmpeg.podspec'
				common_comm_target_pods

	use_expo_modules!			use_expo_modules!
	config = use_native_modules!			config = use_native_modules!
				podfile_properties = JSON.parse(File.read('./Podfile.properties.json')) rescue {}
	use_react_native!(			use_react_native!(
	:path => config[:reactNativePath],			:path => config[:reactNativePath],
	# to enable hermes on iOS, change `false` to `true` and then install pods			# to enable hermes on iOS, change `false` to `true` and then install pods
	:hermes_enabled => podfile_properties['expo.jsEngine'] == 'hermes'			:hermes_enabled => podfile_properties['expo.jsEngine'] == 'hermes'
	)			)

	# Enables Flipper.			# Enables Flipper.
	#			#
	# Note that if you have use_frameworks! enabled, Flipper will not work and			# Note that if you have use_frameworks! enabled, Flipper will not work and
	# you should disable these next few lines.			# you should disable these next few lines.
	use_flipper!({ "Flipper-DoubleConversion" => "1.1.7" })			use_flipper!({ "Flipper-DoubleConversion" => "1.1.7" })
				end

				target 'NotificationService' do
				common_comm_target_pods
				pod 'OLMKit', :path => "../../node_modules/olm"
				pod 'RCT-Folly', :podspec => "../../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec"

				# Lines below are only needed to compile and use Expo Secure Store in Notification Service.
				# If Apple disapproves 'APPLICATION_EXTENSION_API_ONLY' flag then we can safely delete them and use
				# customized Expo Secure Store that does not depend on ExpoModulesCore
				podfile_properties = JSON.parse(File.read('./Podfile.properties.json')) rescue {}
				use_expo_modules!
				use_react_native!(
				:path => "../../node_modules/react-native",
				:hermes_enabled => podfile_properties['expo.jsEngine'] == 'hermes'
				)
				end

	post_install do \|installer\|			post_install do \|installer\|
				ashoatUnsubmitted Not Done Inline Actions Does this apply to all targets now? Are we sure we want to apply it to all targets? Is it possibly that we're inadvertedly applying it to some targets we haven't considered? (Targets that aren't the Comm app, or the notification service extension) ashoat: Does this apply to all targets now? Are we sure we want to apply it to all targets? Is it…
				marcinAuthorUnsubmitted Done Inline Actions There are two changes here compared to master branch: post_install hook is moved from target 'Comm' scope to global Podfile scope some lines are added that disable APPLICATION_EXTENSION_API_ONLY flag to enable CommonCpp sources compilation in 'NotificationService' target. Let me explain why those changes should not raise concern. Ad. 1) According to this doc: https://www.rubydoc.info/github/CocoaPods/Core/Pod%2FPodfile%2FDSL:post_install post_install is a hook applied just before XCode project is written to disk. According to this doc: https://www.rubydoc.info/gems/cocoapods-core/0.34.1/Pod/Podfile/DSL Podfile hooks always exist in global scope. Even if this post_install hook was written inside target 'Comm' scope its behaviour would be the same as if it was in global scope. This is even more confirmed by the fact that an attempt to write multiple post_install hooks (e.g. each per target) leads to errors: https://github.com/CocoaPods/CocoaPods/issues/6172. Ad. 2) Now that we established that we cannot have multiple post_install hooks and the one that we have should be in global scope we can admit it is impossible to use this flag anywhere else. marcin: There are two changes here compared to master branch: 1) post_install hook is moved from target…
				ashoatUnsubmitted Not Done Inline Actions Thanks for the explanation! ashoat: Thanks for the explanation!
	react_native_post_install(installer)			react_native_post_install(installer)
	__apply_Xcode_12_5_M1_post_install_workaround(installer)			__apply_Xcode_12_5_M1_post_install_workaround(installer)

	# Excluding arm64 because M1 simulator isn't supported yet			# Excluding arm64 because M1 simulator isn't supported yet
	# Excluding 32-bit x86 because nobody uses it and it causes compilation issues			# Excluding 32-bit x86 because nobody uses it and it causes compilation issues
	installer.pods_project.build_configurations.each do \|config\|			installer.pods_project.build_configurations.each do \|config\|
	config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64 i386"			config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64 i386"
				ashoatUnsubmitted Not Done Inline Actions It's a bit confusing to me that we exclude both of these here, but in the `project.pbxproj` only `arm64` is mentioned. Do you know why that is? ashoat: It's a bit confusing to me that we exclude both of these here, but in the `project.pbxproj`…
				marcinAuthorUnsubmitted Done Inline Actions Build settings in the XCode project refer to targets: Comm and NotificationService. This line changes build settings for pods. I did not modify this line and according to the explanation above it has alway been that we exclude both architectures for all pods. I do not know why it is that, but it is not related to any change introduced in this diff. Target 'Comm' excluded only amr64 architecture before I started to work on this issue and the very recent changes I introduced were to unify excluded architectures for both Comm and NotificationService. Would you like me to try whether we can exclude i386 arch for XCode targets as well? marcin: Build settings in the XCode project refer to targets: Comm and NotificationService. This line…
				ashoatUnsubmitted Not Done Inline Actions No, that's alright – thanks for this explanation ashoat: No, that's alright – thanks for this explanation
	config.build_settings['OTHER_CPLUSPLUSFLAGS'] = '-DDONT_AUTOINSTALL_REANIMATED'			config.build_settings['OTHER_CPLUSPLUSFLAGS'] = '-DDONT_AUTOINSTALL_REANIMATED'
	end			end

				# Lines below are only needed to compile and use Expo Secure Store in Notification Service.
				# If Apple disapproves 'APPLICATION_EXTENSION_API_ONLY' flag then we can safely delete them and use
				# customized Expo Secure Store that does not depend on ExpoModulesCore
				installer.pods_project.targets.each do \|target\|
				target.build_configurations.each do \|config\|
				config.build_settings['APPLICATION_EXTENSION_API_ONLY'] = 'NO'
				end
	end			end
				ashoatUnsubmitted Not Done Inline Actions There's an extraneous space at the end of this line ashoat: There's an extraneous space at the end of this line
	end			end

[lib] Add userStoreMentionSearchIndex selectorClosedPublicActions

Details

Diff Detail

Event Timeline

Revision ContentsChangeset List

Diff 30289

lib/selectors/user-selectors.js

[lib] Add userStoreMentionSearchIndex selector
ClosedPublic
Actions

Revision Contents
Changeset List