profile
viewpoint
Eli White TheSavior @facebook Redwood City, CA http://eli-white.com React Native @facebook. Circus Enthusiast. Dessert Fanatic. Ex. @wealthfront @airbnb @google @microsoft

reactjs/react-docgen 2564

A CLI and toolbox to extract information from React component files for documentation generation purposes.

cpojer/js-codemod 943

Codemod scripts to transform code to next generation JS

TheSavior/ESLint-Formatter 131

Sublime Text 3 Plugin to Autoformat with Eslint

TheSavior/find-parent 6

A utility for finding the nearest parent that matches a test function

TheSavior/clean-git-ref 3

Clean an input string into a usable git ref

TheSavior/2048 1

A small clone of 1024 (https://play.google.com/store/apps/details?id=com.veewo.a1024)

TheSavior/conservice-charges 1

Visualize your conservice charges over time.

AndyMoreland/hackathon-project-backend 0

The winning hackathon project

pull request commentfacebook/react-native

Change iOS default simulator to iPhone 11 Pro Max

If this change is valid and should be changed for the entire ecosystem then it would belong in the CLI repo. If the CLI maintainers have concerns, they are probably valid and it wouldn't make sense to go around their concerns by putting it here.

codler

comment created time in an hour

delete branch TheSavior/appcenter-docs

delete branch : patch-1

delete time in 4 hours

Pull request review commentDefinitelyTyped/DefinitelyTyped

react-native: add onAccessibilityEscape prop

 export interface AccessibilityPropsIOS {      */     accessibilityViewIsModal?: boolean; +    /**+     * When accessibile is true, the system will invoke this function when the user performs the escape gesture (scrub with two fingers).+     * @platform ios+     */+    onAccessibilityEscape?: () => void;

We have the return type as mixed for many of these callbacks. It indicates that we don’t care about what you return from these functions. Sometimes people want to pass an async function (implicit return of a promise), or some other function they already have.

If we only allow void return types then they have to wrap their callback in another function that doesn’t return anything just to satisfy the checker. So by allowing the return type of mixed the type checker is okay with it and we indicate we don’t look at the return value.

Naturalclar

comment created time in 7 hours

Pull request review commentfacebook/react-native

Change iOS default simulator to iPhone 11 Pro Max

   "private": true,   "scripts": {     "android": "react-native run-android",-    "ios": "react-native run-ios",+    "ios": "react-native run-ios --simulator \"iPhone 11 Pro Max\"",

It seems like run-ios internally should use this simulator as a default if this is desired. Putting it here seems like it is just a hack around the symptom. Also, since it is changing the template it will show up for everyone when they are upgrading.

codler

comment created time in a day

issue commentreact-native-community/discussions-and-proposals

Work out plan to move community to direct debugging

cc @rickhanlonii, as I believe he is working on bringing the Hermes Debugger to Flipper which should make it easy to debug on Android for people using Hermes. I'm not sure if there are plans for iOS though.

Also cc @rsnara and @hramos as TurboModules rolling out will be the forcing function that will make the Chrome Proxy Debugger no longer work. We'll need to have a plan to get people off of that.

acoates-ms

comment created time in a day

Pull request review commentfacebook/react-native

add ripple config object to Pressable

 export default function useAndroidRippleForView(     nativeBackgroundAndroid: NativeBackgroundProp,   |}>, |}> {+  const isSupported = Platform.OS === 'android' && Platform.Version >= 21;+  if (!isSupported || !rippleConfig) {+    return null;+  }   return useMemo(() => {-    if (-      Platform.OS === 'android' &&-      Platform.Version >= 21 &&-      rippleColor != null-    ) {-      const processedColor = processColor(rippleColor);-      invariant(-        processedColor == null || typeof processedColor === 'number',-        'Unexpected color given for Ripple color',-      );+    const {color, borderless, radius} = rippleConfig;+    const processedColor = processColor(color);+    invariant(+      processedColor == null || typeof processedColor === 'number',+      'Unexpected color given for Ripple color',+    ); -      return {-        viewProps: {-          // Consider supporting `nativeForegroundAndroid` and `borderless`.-          nativeBackgroundAndroid: {-            type: 'RippleAndroid',-            color: processedColor,-            borderless: false,-          },-        },-        onPressIn(event: PressEvent): void {-          const view = viewRef.current;-          if (view != null) {-            Commands.setPressed(view, true);-            Commands.hotspotUpdate(-              view,-              event.nativeEvent.locationX ?? 0,-              event.nativeEvent.locationY ?? 0,-            );-          }+    return {+      viewProps: {+        // Consider supporting `nativeForegroundAndroid`+        nativeBackgroundAndroid: {+          type: 'RippleAndroid',+          color: processedColor,+          borderless: borderless === true,+          rippleRadius: radius,         },-        onPressMove(event: PressEvent): void {-          const view = viewRef.current;-          if (view != null) {-            Commands.hotspotUpdate(-              view,-              event.nativeEvent.locationX ?? 0,-              event.nativeEvent.locationY ?? 0,-            );-          }-        },-        onPressOut(event: PressEvent): void {-          const view = viewRef.current;-          if (view != null) {-            Commands.setPressed(view, false);-          }-        },-      };-    }-    return null;-  }, [rippleColor, viewRef]);+      },+      onPressIn(event: PressEvent): void {+        const view = viewRef.current;+        if (view != null) {+          Commands.setPressed(view, true);+          Commands.hotspotUpdate(+            view,+            event.nativeEvent.locationX ?? 0,+            event.nativeEvent.locationY ?? 0,+          );+        }+      },+      onPressMove(event: PressEvent): void {+        const view = viewRef.current;+        if (view != null) {+          Commands.hotspotUpdate(+            view,+            event.nativeEvent.locationX ?? 0,+            event.nativeEvent.locationY ?? 0,+          );+        }+      },+      onPressOut(event: PressEvent): void {+        const view = viewRef.current;+        if (view != null) {+          Commands.setPressed(view, false);+        }+      },+    };+  }, [
React Hook useMemo has a missing dependency: 'rippleConfig'. Either include it or remove the dependency array. (react-hooks/exhaustive-deps)
Lint code: ESLINT
Lint name: react-hooks/exhaustive-deps

I think you need to destructure outside of the method, and use those variables directly in the deps and in the function.

vonovak

comment created time in a day

issue commenttrakt/api-help

How to force user to log in again? OAuth is completing transparently

Thanks for the update! I actually have an update from my end too!

I realized yesterday that the authentication popup is using the same cache as the regular Safari WebView. So if I open my app and sign in with trakt, then open Safari on the phone, I'm signed in on trakt too. If I sign out of the app, then sign back in it does the immediate sign in thing I reported in the OP.

However, if I'm signed in on the app, and then sign out through the app (revoking the token), then open Safari and log out from trakt's website, then the next time I sign in on the app it asks for the credentials.

So maybe if iOS will let me pop an offscreen webview to trakt.tv/logout, I can make that experience work.

It would still be great to get prompt support, but it is at least helpful to have a better understanding of the iOS system! 😀

TheSavior

comment created time in a day

create barnchTheSavior/react

branch : fabric-inspecto

created branch time in a day

issue commentreact-native-community/releases

[changelog] Missing and duplicate entries

Sounds like good approaches to me! Thanks for working on this!

alloy

comment created time in a day

Pull request review commentfacebook/react-native

add ripple config object to Pressable

 export default function useAndroidRippleForView(       };     }     return null;-  }, [rippleColor, viewRef]);

I think rippleconfig is likely to be different every render. Maybe spread the options out first so it does value comparisons on the specific options.

vonovak

comment created time in 3 days

Pull request review commentfacebook/react-native

add ripple config object to Pressable

 export default function useAndroidRippleForView(     if (       Platform.OS === 'android' &&       Platform.Version >= 21 &&-      rippleColor != null+      rippleConfig != null     ) {-      const processedColor = processColor(rippleColor);+      const {color, borderless, radius} = rippleConfig;+      const processedColor = processColor(color);       invariant(         processedColor == null || typeof processedColor === 'number',         'Unexpected color given for Ripple color',       );        return {         viewProps: {-          // Consider supporting `nativeForegroundAndroid` and `borderless`.+          // Consider supporting `nativeForegroundAndroid`           nativeBackgroundAndroid: {             type: 'RippleAndroid',             color: processedColor,-            borderless: false,+            borderless: !!borderless,

I think we prefer being explicit:

borderless: borderless === true

vonovak

comment created time in 3 days

CommitCommentEvent

pull request commentfacebook/react-native

allow custom ripple radius on TouchableNativeFeedback

Hey @vonovak! We just landed a new Pressable component that has very similar code to TouchableNativeFeedback. We didn’t make this same change to it before landing it, would you be willing to make that change? https://github.com/facebook/react-native/commit/3212f7dfe82d187e27f1410c8c3cb1d9fb9f5094

vonovak

comment created time in 5 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

+/**

If ProcessedColorValue goes to processColor.js, and ColorValue stays in StyleSheet, then no product code would ever need to import ColorValueTypes.js

Keeping this file as an implementation details sounds great to me :)

tom-un

comment created time in 5 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

  const AnimatedNode = require('../Animated/src/nodes/AnimatedNode'); -export type ColorValue = null | string;+import type {ColorValue, ProcessedColorValue} from './ColorValueTypes';+import {PlatformColor} from './ColorValueTypes';++export type {ColorValue, ProcessedColorValue};

Why does StyleSheetTypes need to re-export ProcessedColorValue?

I imagine the purpose of re-exporting ColorValue is to be backwards compatible.

tom-un

comment created time in 5 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

+/**+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ *+ * @format+ * @flow strict-local+ */++'use strict';++import type {NativeColorValue} from './PlatformColorValueTypes';

I think this can be merged into the statement below:

import {
  PlatformColor,
  normalizeColorObject,
  processColorObject,
  type NativeColorValue,
} from './PlatformColorValueTypes';
tom-un

comment created time in 5 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

+/**+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ *+ * @format+ * @flow strict-local+ */++'use strict';++import type {NativeColorValue} from './PlatformColorValueTypes';+import {+  PlatformColor,+  normalizeColorObject,+  processColorObject,+} from './PlatformColorValueTypes';++export type {NativeColorValue};+export {PlatformColor, normalizeColorObject, processColorObject};++export type ColorValue = null | string | NativeColorValue;++export type ProcessedColorValue = number | NativeColorValue;

This was nullable in the previous PR, did it change here intentionally?

tom-un

comment created time in 5 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

  import type {TurboModule} from '../../TurboModule/RCTExport'; import * as TurboModuleRegistry from '../../TurboModule/TurboModuleRegistry';+import type {ProcessedColorValue} from '../../StyleSheet/StyleSheetTypes';  export interface Spec extends TurboModule {   +getConstants: () => {|     +HEIGHT: number,     +DEFAULT_BACKGROUND_COLOR: number,   |};-  +setColor: (color: number, animated: boolean) => void;+  +setColor: (color: ProcessedColorValue, animated: boolean) => void;

I think we were going to keep native modules as receiving number for now. Did this one get missed?

tom-un

comment created time in 5 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

Here are some more errors I see in our CI:

stderr: xplat/js/react-native-github/React/Views/RCTView.m:786:50: error: no visible @interface for 'UIColor' declares the selector 'resolvedColorWithTraitCollection:'
[CONTEXT]   CGColorRef backgroundColor = [_backgroundColor resolvedColorWithTraitCollection:self.traitCollection].CGColor;
[CONTEXT]                                 ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Warnings (I'm not sure if these are related to this PR):

xplat/js/react-native-github/Libraries/Text/TextInput/Multiline/RCTUITextView.m:280:3: warning: KVC/KVO key or keypath is not constant [-Wobjc-pika]
  [textAttributes setValue:self.placeholderColor ?: defaultPlaceholderColor() forKey:NSForegroundColorAttributeName];
  ^
xplat/js/react-native-github/Libraries/Text/TextInput/Multiline/RCTUITextView.m:283:5: warning: KVC/KVO key or keypath is not constant [-Wobjc-pika]
    [textAttributes setValue:defaultPlaceholderFont() forKey:NSFontAttributeName];
    ^
2 warnings generated.
xplat/js/react-native-github/Libraries/Text/TextInput/Singleline/RCTUITextField.m:120:5: warning: KVC/KVO key or keypath is not constant [-Wobjc-pika]
    [textAttributes setValue:self.placeholderColor forKey:NSForegroundColorAttributeName];
    ^
tom-un

comment created time in 5 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

Ah, it's probably a haste conflict which is only part of our internal config. Our internal iOS config needs to ignore the .js file. Otherwise it fails saying that the .js and .ios.js resolve to the same Haste name. Alright, I'll just fix this is our internal config.

tom-un

comment created time in 5 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

We are getting flow errors internally about the duplicate module providers for the platform override files:

Error ---------------------------------------------------------------------------
xplat/js/react-native-github/Libraries/StyleSheet/PlatformColorValueTypesIOS.js:1:1
Duplicate module provider for `PlatformColorValueTypesIOS`. Change either this module provider or the current module provider [1].

  xplat/js/react-native-github/Libraries/StyleSheet/PlatformColorValueTypesIOS.js:1:1
  1| /**
     ^

References:
  xplat/js/react-native-github/Libraries/StyleSheet/PlatformColorValueTypesIOS.ios.js:1:1
  1| /**
     ^ [1]

I'm surprised those aren't failing on Circle for this PR. I think the fix is adding the base files to the ignore list in flowconfig, right? Can you make that change?

tom-un

comment created time in 5 days

issue commentreact-native-community/discussions-and-proposals

WIP: Improved TypeScript definitions by generating from Flow source.

Make RN use ES6 imports/exports so these don’t need to be converted; but I’m sure there are reasons why this isn’t done yet.

Nope, no reason other than it hasn't been done. The internal Facebook codebase has been converted other than the react-native repo folder. I'm sure that landing an external PR that does this migration on the entire folder would be difficult, but if there are certain files that are causing you problems where converting those would be helpful, feel free to send PRs for those.

alloy

comment created time in 6 days

delete branch TheSavior/react

delete branch : fabric-focus-blur

delete time in 6 days

push eventfacebook/react

Eli White

commit sha 085d02133e9e3b24ae548d89e4003899bf85022c

[Native] Migrate focus/blur to call TextInputState with the host component (#18068)

view details

push time in 6 days

PR merged facebook/react

[Native] Migrate focus/blur to call TextInputState with the host component CLA Signed

In order to make focus/blur work for Fabric we need to make event targets be a component instance instead of a react tag.

This PR then updates the Renderer integration with TextInputState to handle instances instead of reactTag.

In order to make that work, we have to have an instance.

This changes the HostComponents, making them pass themselves to TextInputState.

Also added tests.

For Facebook employees: This PR will need to land and by synced in conjunction with D19458214

+82 -5

3 comments

5 changed files

TheSavior

pr closed time in 6 days

pull request commentfacebook/react-native

allow custom ripple radius on TouchableNativeFeedback

Thanks! The JS changes seem fine. I defer the review to @mdvacca for the Android changes

vonovak

comment created time in 6 days

pull request commentfacebook/react-native

Add feature: Modal custom background color

Can you provide an example of the current approach required to get this result?

I'm not a big fan of having two props that are conditional on each other so I am curious how difficult the current approach is to be worth this change in API.

gabriel1536

comment created time in 7 days

pull request commentfacebook/react-native

[JavaScript][Removed] - Remove leftover `Incremental` component

Yeah, this is unused! Yay. Thanks for deleting.

venits

comment created time in 7 days

pull request commentfacebook/react-native

Rename autolinking-ios.rb script and bring RNTester and template in line.

Thanks for the bump. Can you rebase this? I'm getting merge conflicts

alloy

comment created time in 7 days

pull request commentfacebook/react-native

Remove JS autoFocus implementation

Thanks for the pings!

janicduplessis

comment created time in 7 days

PR opened facebook/react

[Native] Migrate focus/blur to call TextInputState with the host component

TextInputState has been expecting the reactTag of the text input. D19458214 makes it now expect a host component.

+82 -5

0 comment

5 changed files

pr created time in 7 days

create barnchTheSavior/react

branch : fabric-focus-blur

created branch time in 7 days

PR closed facebook/react

[DO-NOT-MERGE][Native] Migrate focus/blur to call TextInputState with the host component CLA Signed

In order to make focus/blur work for Fabric we need to make event targets be a component instance instead of a react tag.

That PR has landed behind a feature flag. Before we can land this we need that to roll out completely and flip the feature flag on by default.

This PR then updates the Renderer integration with TextInputState to handle instances instead of reactTag.

In order to make that work, we have to have an instance. Which means that components with NativeMethodsMixin and ReactNative.NativeComponent will no longer be able to call .focus or .blur. This is a breaking change but we are okay with that. For Fabric components implemented with those aren't supported anyways.

This changes the HostComponents, making them pass themselves to TextInputState.

Also added tests.

For Facebook employees: This PR will need to land and by synced in conjunction with D19458214

+272 -17

3 comments

7 changed files

TheSavior

pr closed time in 7 days

delete branch TheSavior/react

delete branch : fabric-focus-blur

delete time in 7 days

issue commentreact-native-community/cli

Reload/open dev menu commands don't work reliably (watch mode)

I defer to @rickhanlonii here

lucasbento

comment created time in 8 days

pull request commentfacebook/react-native

Migrate AppContainer to new Context API

I think it is fine to leave the usage of prop-types for now, as long as we know we are making progress towards removing it. I'm not sure if the React API requires the usage of prop-types for the old context API. If we can avoid it, great! Otherwise, I'm not so worried as long as we have a plan.

safaiyeh

comment created time in 8 days

pull request commentfacebook/react-native

Migrate AppContainer to new Context API

To make it backwards compatible could you leave the existing code:

static childContextTypes:
    | any
    | {|rootTag: React$PropType$Primitive<number>|} = {
    rootTag: PropTypes.number,
  };

  getChildContext(): Context {
    return {
      rootTag: this.props.rootTag,
    };
  }

but make rootTag in here a getter?

    return {
      rootTag: this.props.rootTag,
    };

And then also render <Context.Provider value={{rootTag: this.props.rootTag}}>?

safaiyeh

comment created time in 8 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

Fix: ref type in Animated Component

 export namespace Animated {     export type ComponentProps<T> = T extends React.ComponentType<infer P> | React.Component<infer P> ? P : never;      export interface WithAnimatedValue<T>-      extends ThisType<-        T extends object-          ? { [K in keyof T]?: WithAnimatedValue<T[K]> }-          : T extends (infer P)[]-          ? WithAnimatedValue<P>[]-          : T | Value | AnimatedInterpolation-        > {}--    export type AnimatedProps<T> = { [key in keyof T]: WithAnimatedValue<T[key]> };--    export interface AnimatedComponent<T extends React.ComponentType<ComponentProps<T>> | React.Component<ComponentProps<T>>> extends React.FC<AnimatedProps<ComponentProps<T>>> {-        getNode: () => T;-    }+    extends ThisType<+      T extends object+        ? { [K in keyof Omit<T, 'ref'>]?: WithAnimatedValue<T[K]> }+        : T extends (infer P)[]+        ? WithAnimatedValue<P>[]+        : T | Value | AnimatedInterpolation+    > {}++  export type AnimatedProps<T> = { [key in keyof T]: WithAnimatedValue<T[key]> };++  export interface AnimatedComponent<+    T extends React.ComponentType<ComponentProps<T>> | React.Component<ComponentProps<T>>+  >+    extends React.FC<+      AnimatedProps<ComponentProps<T>> & {+        ref?:+          | React.RefObject<AnimatedComponent<T> | undefined>

Does this also include the ref callback form? ref={(ref) => ...}

zusinShinpei

comment created time in 8 days

pull request commentfacebook/react-native

Migrate AppContainer to new Context API

Thanks for working on this!

It looks like it is pretty common to consume this rootTag context downstream. Class components access this.context.rootTag to pass to native modules for example.

I think this would be a fairly substantial breaking change as is, do you have any ideas of how to make this backwards compatible and make it easy to migrate?

For an example, take a look at Modal.js, I think one of the usages of context there is to receive this context type.

I'd love to see your test plan include the RNTester examples for Modal. Ideally, first without any changes to the JS code and a warning being printed recommending to use the new way to consume this API, and second changing the Modal code to consume the context in the new way.

This will hopefully make sure the necessary pieces are exported for downstream consumers to use the context, and for it to be backwards compatible for now.

safaiyeh

comment created time in 8 days

issue openedfacebook/react-native

Migrate off of old context APIs

We want to get rid of our usage of the prop-types package. The last remaining usage of this is a couple of old components that use the old React context API. We need to migrate these components to use the modern React.createContext API.

The components using the old context API are:

For more information about the old API and how to migrate to the new API you can check out the React docs for Context: https://reactjs.org/docs/context.html#classcontexttype

If we are able to remove the usage of prop-types from React Native we should be able to substantially lower the bundle size of React Native. We'd love your help!

created time in 8 days

CommitCommentEvent
CommitCommentEvent

pull request commentfacebook/react-native

bump @typescript-eslint and prettier versions in eslint-config

@hramos might be able to help with updating these packages

dulmandakh

comment created time in 8 days

pull request commentreact-native-community/discussions-and-proposals

React Native Test App as a Package

@tido64, ah. I understand better now. If you want to make this a default part of creating new modules, I don't think react-native init is the right place as that is mostly known for creating end user apps. After a quick google search, I found these two projects that seem to be for helping bootstrap a new native module / component: bob, and creat-react-native-module.

tido64

comment created time in 9 days

push eventTheSavior/thesavior.github.io

Eli White

commit sha 024a83b076fa621aa44a89ecdbd4e543363a1cd4

Add Next Show Privacy Policy

view details

push time in 10 days

push eventTheSavior/thesavior.github.io

Eli White

commit sha 03ab428865b390880ace16d2fddb3c9660de2466

Add Next Show Privacy Policy

view details

push time in 10 days

pull request commentfacebook/react-native

allow custom ripple radius on TouchableNativeFeedback

Thanks! Can you update your PR summary with a video of the new RNTester example? That way we can look back at this PR to remember how it was supposed to work when it is refactored in the future. :)

vonovak

comment created time in 11 days

pull request commentfacebook/react-native

Rename autolinking-ios.rb script and bring RNTester and template in line.

Can you rebase on top of master? I got some merge conflicts when importing. Looks like one of these files may have been changed since

alloy

comment created time in 11 days

pull request commentfacebook/react-native

Rename autolinking-ios.rb script and bring RNTester and template in line.

Can you rebase on top of master? I got some merge conflicts when importing. Looks like this file may have been changed since

alloy

comment created time in 11 days

pull request commentfacebook/react-native

allow custom ripple radius on TouchableNativeFeedback

The ripples that go inwards instead of outwards seem weird to me, is that intended?

Also, can you add examples to RNTester that demonstrate this behavior?

vonovak

comment created time in 11 days

issue commenttrakt/api-help

How to force user to log in again? OAuth is completing transparently

My new request is this:

const req = {
      method: 'POST',
      url: `${this._settings.endpoint}/oauth/revoke`,
      headers: {
        'User-Agent': this._settings.useragent,
        'Content-Type': 'application/json',
        Authorization: `Bearer ${this._authentication.access_token}`,
        'trakt-api-version': '2',
        'trakt-api-key': this._settings.client_id,
      },
      body: JSON.stringify({
        token: this._authentication.access_token,
        client_id: this._settings.client_id,
        client_secret: this._settings.client_secret,
      }),
    };

which resolves to (with substitutions so I can post on GitHub):

{
  "method": "POST",
  "url": "https://api.trakt.tv/oauth/revoke",
  "headers": {
    "User-Agent": "app1234/0.0.1 (NodeJS)",
    "Content-Type": "application/json",
    "Authorization": "Bearer MY_TOKEN",
    "trakt-api-version": "2",
    "trakt-api-key": "MY_TOKEN"
  },
  "body": "{\"token\":\"MY_TOKEN\",\"client_id\":\"MY_CLIENT_ID\",\"client_secret\":\"MY_CLIENT_SECRET\"}"
}

I still get a json response from the server of {}, and the result is the same. The next authentication is still resolved immediately and transparently without the user being prompted for anything. 😢

TheSavior

comment created time in 12 days

push eventfacebook/react

Eli White

commit sha 2d6be757df86177ca8590bf7c361d6c910640895

[Native] Delete NativeComponent and NativeMethodsMixin (#18036) * [Native] Delete NativeComponent and NativeMethodsMixin * Remove more files

view details

push time in 12 days

PR merged facebook/react

Reviewers
[Native] Delete NativeComponent and NativeMethodsMixin CLA Signed

Summary

NativeComponent and NativeMethodsMixins were JS APIs for creating components that proxied the methods to the underlying host component by using findNodeHandle. Nothing in core uses these anymore, core uses forwardRef instead. We can finally delete these!

These APIs weren't exposed as part of the public API of React Native so this isn't a breaking change.

Test Plan

Jest, Flow. I also imported this diff into Facebook to run a build size bot and mobile lab. Diff here: https://our.internmc.facebook.com/intern/diff/D19458361/

+260 -1257

3 comments

10 changed files

TheSavior

pr closed time in 12 days

PR opened facebook/react

[Native] Delete NativeComponent and NativeMethodsMixin

Summary

NativeComponent and NativeMethodsMixins were JS APIs for creating components that proxied the methods to the underlying host component by using findNodeHandle. Nothing in core uses these anymore, core uses forwardRef instead. We can finally delete these!

These APIs weren't exposed as part of the public API of React Native so this isn't a breaking change.

Test Plan

Jest, Flow. I also imported this diff into Facebook to run a build size bot and mobile lab. Diff here: https://our.internmc.facebook.com/intern/diff/D19458361/

+260 -1257

0 comment

10 changed files

pr created time in 12 days

push eventTheSavior/react

Eli White

commit sha 69a7f782f38913cf03ccf2b8d18001e42470148c

Remove more files

view details

push time in 12 days

create barnchTheSavior/react

branch : delete-nativecomponent-mixin

created branch time in 12 days

issue commenttrakt/api-help

How to force user to log in again? OAuth is completing transparently

I've also tried hitting the api endpoint, as well as trying to include my client_secret in the body.

TheSavior

comment created time in 12 days

issue commenttrakt/api-help

How to force user to log in again? OAuth is completing transparently

Thanks for the response!

I'm revoking the token with this code:

const req = {
      method: 'POST',
      url: 'https://trakt.tv/oauth/revoke',
      headers: {
        'User-Agent': this._settings.useragent,
        'Content-Type': 'application/json',
        Authorization: `Bearer ${this._authentication.access_token}`,
        'trakt-api-version': '2',
        'trakt-api-key': this._settings.client_id,
      },
      body: JSON.stringify({
        token: this._authentication.access_token,
        client_id: this._settings.client_id,
      }),
    };

    return fetch(req.url, req);

I ran this against the apiary debug url endpoint and it seemed like it was happy with my request shape.

TheSavior

comment created time in 12 days

pull request commentDefinitelyTyped/DefinitelyTyped

react-native/requireNativeComponent - changing to correct definition

Would you be willing to send a PR to the docs instead?

puhfista

comment created time in 12 days

issue commentfacebook/react-native

Memory growth

A more focused repro would definitely be better

DanielPiflaks

comment created time in 12 days

pull request commentreact-native-community/discussions-and-proposals

Move iOS and Android Specific Code to Their Own Packages

I think the people on our team at FB want these pieces separated as well. However, this is major refactoring work that can only be accomplished internally, so it’s probably a ways out. Probably at least a year until anything could actually happen here unfortunately. We have lots of other projects we have to focus on first. :-)

empyrical

comment created time in 12 days

issue commenttrakt/api-help

How to force user to log in again? OAuth is completing transparently

This issue is interesting and definitely related: https://github.com/trakt/api-help/issues/19#issuecomment-457733626

The recommendation is to authenticate against the trakt.tv endpoint and not api.trakt.tv. This is a good gotcha, every JS library for Trakt I've seen authenticates against api.trakt.tv.

Regardless, from that issue it seems like I would still need to manually hit /logout. Unfortunately I don't think I can open a browser with the same cookie jar to be able to call /logout since the iOS authentication framework is separate.

I think I'm out of ideas

TheSavior

comment created time in 13 days

issue openedtrakt/api-help

How to force user to log in again? OAuth is completing transparently

I have OAuth working in my app, but I can't seem to figure out how to make logging out work. When they press log out I revoke the token through the API and then clear my app state. When the user chooses to log back in, the oauth authentication screen pops up but still instantly closes.

This issue is the same as in this issue: https://github.com/openid/AppAuth-iOS/issues/281

traktsignout

They recommend adding prompt=login to the request as that seems to be part of the OAuth spec for the server to force the user to enter credentials again. However, either I haven't implemented that correctly, or the Trakt API doesn't support it. 😀 Here is another article about that: https://www.oauth.com/oauth2-servers/authorization/requiring-user-login/

created time in 13 days

Pull request review commentreact-native-community/releases

0.62.0 changelog

 # Changelog +## [v0.62.0-rc.0.1]++### Breaking++- Remove <TextInput>'s `onTextInput` event ([3f7e0a2](https://github.com/facebook/react-native/commit/3f7e0a2) by [@shergin](https://github.com/shergin))+- Restore behavior for `underlayColor={null}` in `TouchableHighlight`. ([37d8440](https://github.com/facebook/react-native/commit/37d8440) by [@yungsters](https://github.com/yungsters))++### Added++- Remove requestAnimationFrame when focusing input on mount ([5798cf2](https://github.com/facebook/react-native/commit/5798cf2) by [@janicduplessis](https://github.com/janicduplessis))+- Add missing `console` polyfills in release builds ([b7ab922](https://github.com/facebook/react-native/commit/b7ab922) by [@yungsters](https://github.com/yungsters))

Thanks!

Most of those commits specify a Changelog in the commit summary. I'm surprised these didn't show up in the changelog originally, that seems like a bug. @jeremy-deutsch, maybe you'd like to also investigate that? The code for the changelog generator is here: https://github.com/react-native-community/releases/blob/master/changelog-generator.js

It's also fine if you don't want to do that :)

kelset

comment created time in 13 days

pull request commentreact-native-community/discussions-and-proposals

React Native Test App as a Package

I love this. I think making it easier for module owners to verify their modules works on different versions will be great.

I'm a little nervous about this part

Aim to become part of the default create-react-native-app template

The scenario for people who maintain apps to test against other versions seems like a bit of a different problem to me. For example, they probably don't need to make sure their app works across multiple versions of React Native.

Do you see it as important to support app developers with this tool? Or does it make sense to have it be focused on library authors / platform authors?

tido64

comment created time in 13 days

issue commentreact-native-community/react-native-webview

Tracking Issue: Fabric support

FWIW, this doesn't necessarily have anything to do with Fabric. We think these are just cleaner APIs even for React Native today. Fabric's removal of findNodeHandle doesn't require these changes, it just makes the cleaner API even nicer.

It's also worth noting that doing this isn't the only thing required to support Fabric. There will be documentation for the native changes required as it gets closer.

The comment about getScrollableNode being removed in a future release isn't really related to Fabric either. That call in Animated only exists as an implementation detail to work with ScrollView. Defining that method in WebView in order to get the same behavior is essentially like depending on internals. Once we change ScrollView to have the cleaner APIs and not need getScrollableNode, we will no longer need that check in createAnimatedComponent, at which point things would break here.

All that said, yep, your changes to iOS look good to me. I'm not sure how this pattern should get typed in TypeScript but I imagine Microsoft and the TypeScript team will need to work on figuring it out as 0.62 rolls out. In fact that issue is being tracked here: https://github.com/facebook/react-native/issues/27997

shirakaba

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

Oh, by all means. Definitely don't consider anything I'm saying blocking. You should do whatever your libary needs to do. We'll figure out the rest later as things get closer and we start helping modules migrate. 👍

shirakaba

comment created time in 14 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

@RSNara, I don't think we can use Object as the type because it would need to be number | Object which the native module codegen doesn't support, right?

Do you agree that for now it is probably easiest to keep native modules only supporting number, and at a later point making the native module codegen support ProcessedColorValue and opening them up to any color type then?

tom-un

comment created time in 14 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

Ah, that's a good point. That's kind of a reserved name for the native module schemas and components.

@tom-un, what about instead of NativeColorValueType.js, PlatformColorValueType.js. Does that still make sense in context?

tom-un

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

Is this adorning your ref to the host component with a few methods from the class component instance?

Yep, exactly. When you attach a ref to the TextInput, you get access to all the public methods from the JS component as well as the native methods like measure. This is why people don't have to worry about the implementation anymore. 😀

shirakaba

comment created time in 14 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 class Share {           'NativeActionSheetManager is not registered on iOS, but it should be.',         ); +        const processedTintColor = processColor(tintColor);

Is this processing it again? It looks like tintColor was already processed on line 110

tom-un

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

TextInput has a bit of both (clear() still exists on the class component)

Can you elaborate what you mean by this?

shirakaba

comment created time in 14 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 const ActionSheetIOS = {       destructiveButtonIndices = [destructiveButtonIndex];     } +    const processedTintColor = processColor(tintColor);+    invariant(typeof processedTintColor === 'number', 'tintColor must be a simple RGBA value');

I think saying RGBA can be confusing since it doesn't require rgba(). Maybe just Unexpected color given for tintColor?

tom-un

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

Another example is ref.measureLayout. The ref there has to be a host component, but so does the argument it is comparing to:

textInputRef.measureLayout( scrollViewRef, (left, top, width, height) => { scrollViewRef.scrollResponderScrollNativeHandleToKeyboard( textInputRef, height + 10, });


If we didn't do this, then if you wanted to measure a TextInput's location inside of a ScrollView you'd need to know that you actually have to do this:

textInputRef.getNativeInputRef().measureLayout( scrollViewRef.getNativeScrollViewRef(), (left, top, width, height) => { scrollViewRef.scrollResponderScrollNativeHandleToKeyboard( textInputRef.getNativeInputRef(), height + 10, });


FWIW, we are only trying to do this in core. We aren't trying to enforce this on community components. I'm sharing our approach in case this approach is also interesting for WebView. 

Back to the meta point, you should expect `getScrollableNode`'s support in createAnimatedComponent to go away in the future.
shirakaba

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

We are making these changes to make it easier for people to adopt Fabric. Fabric doesn't have findNodeHandle so it is important for people to be able to get to the underlying native component directly. I agree that JS components could have a getter that provides that ref.

For core components we don't want people to be confused by having to know which components are native components and you can call the methods like measure directly, and which are JS components where you need to call some unknown named getter first.

For example, I think it is reasonable for people to expect that ScrollView is a native component. However, it is actually a JS component and has methods like scrollTo, but if you want to call measure you have to call getNativeScrollRef first. That means that the distinction between what is implemented in JS and what is implemented in native is part of the public API and people have to just know this.

By making the change to have the ref work as a native component but also include all the JS methods, nobody has to know the distinction.

shirakaba

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

This is what I'm referring to:

https://github.com/facebook/react-native/blob/7813e24cdb55b0716df019edc0d875730bf65169/Libraries/Components/TextInput/TextInput.js#L1014-L1047

This works now:

<TextInput ref={ref => { 
    ref.measure(() => {
      ref.clear();
    })
  }} />

Instead of what was required previously:

<TextInput ref={ref => { 
    ref.getNativeViewRef().measure(() => {
      ref.clear();
    })
  }} />
shirakaba

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

Yeah, to solve that we have been attaching the wrapper JS component methods to the native ref. Check out TextInput.js in core for an example.

This has helped enable us remove the need for getScrollableNode in user code, although the implementation details are a bit gross

shirakaba

comment created time in 14 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 type NativeProps = $ReadOnly<{|    on?: ?boolean,   enabled?: boolean,-  tintColors: {|true: ?number, false: ?number|} | typeof undefined,+  tintColors:

Why do these take ColorValue as well as ProcessedColorValue? I'd expect them to only take ProcessedColorValue.

tom-un

comment created time in 14 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 type Props = $ReadOnly<{|    *    * See http://facebook.github.io/react-native/docs/activityindicator.html#color    */-  color?: ?string,+  color?: ?ColorValue,

I think this change requires this line to change too. It probably doesn't fail flow because of the $FlowFixMe lower in this file. https://github.com/facebook/react-native/blob/master/Libraries/Components/ProgressBarAndroid/ProgressBarAndroid.android.js#L52

tom-un

comment created time in 14 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 export interface Spec extends TurboModule {       +destructiveButtonIndices?: ?Array<number>,       +cancelButtonIndex?: ?number,       +anchor?: ?number,-      +tintColor?: ?number,+      +tintColor?: ?ProcessedColorValue,

I'm realizing that this change to the spec will require rebuilding the generated native code and making sure that the native module correctly supports the new type.

I'm not sure how these specs need to be updated, cc @RSNara

tom-un

comment created time in 14 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

react-native: add some missing props for TextInput

 export interface TextInputIOSProps {     | 'newPassword'     | 'oneTimeCode'; +

Unnecessary blank lines?

Naturalclar

comment created time in 14 days

pull request commentreact-native-community/react-native-webview

feat: implement getScrollableNode to support Animated.

My understand was that the webview component needs to use forwardRef to the native webview component so that when you call getNode you get the native component and don’t then need to also call getScrollableNode.

shirakaba

comment created time in 14 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

Great, re topic 2, I’m on board with the existing functions too then.

Re: naming, I agree that I’m 50/50 and that the first reads better and the second follows precedence. I think on our team as we were discussing we couldn’t come up with a strong argument for why we should break trend and use prefixes, so suffixes probably make more sense and are more likely what people would expect.

Does that sound reasonable to you or do you have more reasons for prefix?

tom-un

comment created time in 15 days

pull request commentfacebook/react-native

PlatformColor implementations for iOS and Android

Re: The question about the API being prefixed like IOSDynamicColor or suffixed, DynamicColorIOS. I'm responding at the top level here because its a larger response and I don't want it to get lost.

Thanks for bringing this up. I don't really have strong opinions on this so in general being consistent is probably better. I asked around on the team at FB as well to get some other thoughts. It's possible there are too many cooks, but here are the thoughts.

This is what I believe the current proposal has right now:

Platform.select({
  ios: IOSDynamicColor({
    dark: ,
    light: ,
  }),
  android: AndroidColor(),
  windows: WindowsBrush(),
})

There was a preference from the team for suffixes over prefixes to be consistent. That would result in the following:

Platform.select({
  ios: DynamicColorIOS({
    dark: ,
    light: ,
  }),
  android: ColorAndroid(),
  windows: BrushWindows(),
})

These kinda seem strange since there isn't also a DynamicColorAndroid. The question then was why these need different names. Could they all be one name? Maybe something like ColorFor___, which would result in this:

{
  backgroundColor: 
    Platform.select({
      ios: ColorForIOS({dark, light}),
      android: ColorForAndroid('@color/catalyst_redbox_background'),
      windows: ColorForWindows({someBrushConfig})
    })
}

I think that is probably the least surprising and most consistent option.

Then a crazy idea was added to the pool of ideas. The downside of any of these options is that you need to import multiple things, and you probably always need to use a Platform.select or something equivalent when using these APIs, although I guess that isn't true if you are only building for one platform (maybe that's a good reason to not do the following idea).

So then the question was what if the API essentially had Platform.select built in and didn't require the additional imports. It could look something like this:

{
  backgroundColor: 
    Platform.color({
      ios: {dark, light},
      android: '@color/catalyst_redbox_background',
      windows: {someBrushConfig},
      default: '#fcfcfc',
    })
}

It's totally possible that a change like this is out of scope, would be too problematic with types, or some other issue. I wanted to bring it up now in case you had thoughts on it, but would totally be on board with a change like this being out of scope and the answer being that we'll make that change later if we find it to be better once platform colors are actually being used.

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

+/**+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ *+ * @format+ * @flow strict-local+ */++'use strict';++import type {ColorValue, ProcessedColorValue} from './ColorValueTypes';++export opaque type NativeColorValue = {+  semantic?: Array<string>,+  dynamic?: {+    light: ?(ColorValue | ProcessedColorValue),+    dark: ?(ColorValue | ProcessedColorValue),+  },+};++export const PlatformColor = (...names: Array<string>): ColorValue => {+  return {semantic: names};+};++export type IOSDynamicColorTuplePrivate = {+  light: ColorValue,+  dark: ColorValue,+};++export const IOSDynamicColorPrivate = (+  tuple: IOSDynamicColorTuplePrivate,+): ColorValue => {+  return {dynamic: {light: tuple.light, dark: tuple.dark}};+};++export const normalizeColorObject = (+  color: NativeColorValue,+): ?ProcessedColorValue => {+  if ('semantic' in color) {+    // an ios semantic color+    return color;+  } else if ('dynamic' in color && color.dynamic !== undefined) {

Yeah, we don't allow != undefined, only != null. I think I'd still prefer != null

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 module.exports = {   get processColor(): processColor {     return require('./Libraries/StyleSheet/processColor');   },+  get PlatformColor(): PlatformColor {

Do we need to export the color functions for ios and android as well?

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 public DoublePropSetter(ReactPropGroup prop, Method setter, int index, double de     }      @Override-    protected Object getValueOrDefault(Object value) {+    protected Object getValueOrDefault(Object value, Context context) {       return value == null ? mDefaultValue : (Double) value;     }   } +  private static class ColorPropSetter extends PropSetter {+    private static final String JSON_KEY = "resource_paths";+    private static final String PREFIX_RESOURCE = "@";+    private static final String PREFIX_ATTR = "?";+    private static final String PACKAGE_DELIMITER = ":";+    private static final String PATH_DELIMITER = "/";+    private static final String ATTR = "attr";+    private static final String ATTR_SEGMENT = "attr/";++    private final int mDefaultValue;++    public ColorPropSetter(ReactProp prop, Method setter) {+      super(prop, "mixed", setter);+      mDefaultValue = 0;+    }++    public ColorPropSetter(ReactProp prop, Method setter, int defaultValue) {+      super(prop, "mixed", setter);+      mDefaultValue = defaultValue;+    }++    @Override+    protected Object getValueOrDefault(Object value, Context context) {+      if (value == null) {+        return mDefaultValue;+      }++      if (value instanceof Double) {+        return ((Double) value).intValue();+      }++      if (context == null) {+        throw new RuntimeException("Context may not be null.");+      }++      if (value.getClass() == ReadableMap.class || value.getClass() == ReadableNativeMap.class) {+        ReadableMap map = (ReadableMap) value;+        ReadableArray resourcePaths = map.getArray(JSON_KEY);++        if (resourcePaths == null) {+          throw new JSApplicationCausedNativeException("ColorValue: The `" + JSON_KEY + "` must be an array of color resource path strings.");+        }++        for (int i = 0; i < resourcePaths.size(); i++) {+          String resourcePath = resourcePaths.getString(i);++          if (resourcePath == null || resourcePath.isEmpty()) {+            continue;+          }++          boolean isResource = resourcePath.startsWith(PREFIX_RESOURCE);+          boolean isThemeAttribute = resourcePath.startsWith(PREFIX_ATTR);++          resourcePath = resourcePath.substring(1);++          try {+            if (isResource) {+              return resolveResource(context, resourcePath);+            } else if (isThemeAttribute) {+              return resolveThemeAttribute(context, resourcePath);+            }+          } catch (Resources.NotFoundException exception) {+            exception.printStackTrace();

It seems like you wouldn't want it to log if it is intended behavior. Especially if the error message that is thrown if none of them match is sufficiently helpful

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

+/**+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ *+ * @format+ * @flow strict-local+ */++'use strict';++import type {ColorValue, ProcessedColorValue} from './ColorValueTypes';++export opaque type NativeColorValue = {+  semantic?: Array<string>,+  dynamic?: {+    light: ?(ColorValue | ProcessedColorValue),+    dark: ?(ColorValue | ProcessedColorValue),+  },+};++export const PlatformColor = (...names: Array<string>): ColorValue => {+  return {semantic: names};+};++export type IOSDynamicColorTuplePrivate = {+  light: ColorValue,+  dark: ColorValue,+};++export const IOSDynamicColorPrivate = (+  tuple: IOSDynamicColorTuplePrivate,+): ColorValue => {+  return {dynamic: {light: tuple.light, dark: tuple.dark}};+};++export const normalizeColorObject = (+  color: NativeColorValue,+): ?ProcessedColorValue => {+  if ('semantic' in color) {+    // an ios semantic color+    return color;+  } else if ('dynamic' in color && color.dynamic !== undefined) {

Do you specifically want to have different behavior if color.dynamic is null here vs undefined? Otherwise != vs !==

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 class DrawerLayoutAndroid extends React.Component<Props, State> {       ...props     } = this.props;     const drawStatusBar =-      Platform.Version >= 21 && this.props.statusBarBackgroundColor;+      Platform.Version >= 21 && this.props.statusBarBackgroundColor !== null;

!=

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 function normalizeColor(color: string | number): ?number {     return null;   } +  if (typeof color === 'object' && color !== null) {+    const normalizeColorObject = require('./NativeColorValueTypes')+      .normalizeColorObject;++    const normalizedColorObj = normalizeColorObject(color);++    if (normalizedColorObj !== null) {

same here

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 function normalizeColor(color: string | number): ?number {     return null;   } +  if (typeof color === 'object' && color !== null) {

Let's use != null

tom-un

comment created time in 15 days

Pull request review commentfacebook/react-native

PlatformColor implementations for iOS and Android

 const Platform = require('../Utilities/Platform');  const normalizeColor = require('./normalizeColor');+import type {ColorValue, ProcessedColorValue} from './ColorValueTypes';  /* eslint no-bitwise: 0 */-function processColor(color?: ?(string | number)): ?number {+function processColor(color?: ?(number | ColorValue)): ?ProcessedColorValue {   if (color === undefined || color === null) {     return color;   } -  let int32Color = normalizeColor(color);-  if (int32Color === null || int32Color === undefined) {+  let normalizedColor = normalizeColor(color);+  if (normalizedColor === null || normalizedColor === undefined) {     return undefined;   } +  if (typeof normalizedColor === 'object') {+    const processColorObject = require('./NativeColorValueTypes')+      .processColorObject;++    const processedColorObj = processColorObject(normalizedColor);++    if (processedColorObj !== null) {

Since the flow type for processColorObject is ?NativeColorValue, we normally would make this != instead of !==

tom-un

comment created time in 15 days

pull request commentfacebook/react-native

Remove JS autoFocus implementation

Thanks for the ping!

Looks like I can't land this yet. Let's check again on 2/17! :)

janicduplessis

comment created time in 15 days

issue commentfacebook/react-native

LayoutAnimation crashes on Android

@k3nada, can you put that into a complete example into an expo snack that crashes. See my comment above.

gdoudeng

comment created time in 15 days

Pull request review commentfacebook/react-native

chore: add description for rejectResponderTermination prop

 type IOSProps = $ReadOnly<{|   PasswordRules?: ?PasswordRules,    /*+   * If `true`, allows TextInput to pass touch events to the parent component.+   * This allows components such as SwipeableListView to be swipeable from the TextInput on iOS,

SwipeableListView doesn't exist anymore

Naturalclar

comment created time in 17 days

pull request commentfacebook/react-native

fix: prop name for passwordRules

Thanks for adding the documentation too

Naturalclar

comment created time in 17 days

PR opened MicrosoftDocs/appcenter-docs

Fix command in docs to get deployment keys for code push

Before:

$ appcenter codepush deployment ls EliWhite/TriTowersTD -k
Error: Command 'codepush deployment ls EliWhite/TriTowersTD -k' failed with exception "Unknown argument -k"
$ appcenter codepush deployment ls -a EliWhite/TriTowersTD -k
Error: Command 'codepush deployment ls -a EliWhite/TriTowersTD -k' failed with exception "Unknown argument -a"

After:

appcenter codepush deployment list -a EliWhite/TriTowersTD -k
┌────────────┬───────────────────────────────────────┐
│ Name       │ Key                                   │
├────────────┼───────────────────────────────────────┤
│ Staging    │ ---------------- │
├────────────┼───────────────────────────────────────┤
│ Production │ -------------- │
└────────────┴───────────────────────────────────────┘

+1 -1

0 comment

1 changed file

pr created time in 18 days

push eventTheSavior/appcenter-docs

Eli White

commit sha 13be2f8082594fab38aa07899684dad59b942b95

Fix command to get deployment keys Before: ``` $ appcenter codepush deployment ls EliWhite/TriTowersTD -k Error: Command 'codepush deployment ls EliWhite/TriTowersTD -k' failed with exception "Unknown argument -k" $ appcenter codepush deployment ls -a EliWhite/TriTowersTD -k Error: Command 'codepush deployment ls -a EliWhite/TriTowersTD -k' failed with exception "Unknown argument -a" ``` After: ``` appcenter codepush deployment list -a EliWhite/TriTowersTD -k ┌────────────┬───────────────────────────────────────┐ │ Name │ Key │ ├────────────┼───────────────────────────────────────┤ │ Staging │ ---------------- │ ├────────────┼───────────────────────────────────────┤ │ Production │ -------------- │ └────────────┴───────────────────────────────────────┘ ```

view details

push time in 18 days

fork TheSavior/appcenter-docs

content repo for Visual Studio App Center on docs.microsoft.com

https://docs.microsoft.com/appcenter/

fork in 18 days

issue commentreact-native-community/releases

0.62.x RC Discussion

There are some TypeScript changes that should be shipped as part of 0.62.0, I created an issue to track that for @alloy here: https://github.com/facebook/react-native/issues/27997

kelset

comment created time in 18 days

more