Skip to content
This repository has been archived by the owner on Jun 17, 2022. It is now read-only.

0.58.3 Discussion #81

Closed
grabbou opened this issue Jan 24, 2019 · 34 comments
Closed

0.58.3 Discussion #81

grabbou opened this issue Jan 24, 2019 · 34 comments
Labels
backport request Cherry picking a change into an existing release stable Stable version

Comments

@grabbou
Copy link
Member

grabbou commented Jan 24, 2019

Conversation on this thread are limited to 0.58.0 release's major issues and backport (cherry-pick) requests from commits that are already on master - so that we can then produce a 0.58.4 release in the near future.

An example of a good such request is a bug fix for a serious issue that has been merged into master but did not make the 0.58.3 cut.

In other words, if you cannot point to a particular commit on master, then your request likely belongs as a new issue in http://github.com/facebook/react-native/issues.

If the commit you request to cherry pick is a complicated port, you will be asked to create the PR to the 0.58-stable branch yourself, in order to ensure that the process proceeds smoothly.

@grabbou grabbou added stable Stable version backport request Cherry picking a change into an existing release labels Jan 24, 2019
@Jyrno42
Copy link

Jyrno42 commented Jan 25, 2019

@Bardiamist
Copy link
Contributor

Bardiamist commented Jan 25, 2019

I created react-native@0.58.0 project and here flow-bin@0.85.0 (not flow-bin@0.86.0 as desribed in changelog) therefore required and flow-bin0.86.0 commit facebook/react-native@8fb228f

@zenz
Copy link

zenz commented Jan 28, 2019

flow still not work under windows. but arm64 supported is a good thing.

@grabbou
Copy link
Member Author

grabbou commented Jan 28, 2019

@Bardiamist looks like the Flow 0.86 commit has been reverted by a mistake few commits after. I am not entirely sure how it happened, I am going to check it and release a patch.

@grabbou
Copy link
Member Author

grabbou commented Jan 28, 2019

Looks like Flow commit was not the only one that was accidentally reverted while we were working on a 0.58 release candidate. Apologies for the confusion, as the commits were listed in the changelog.

Here is a full list of commits that are being released under 0.58.2: facebook/react-native@de60e86...8f283b9

@grabbou grabbou changed the title 0.58.0 Discussion 0.58.2 Discussion Jan 28, 2019
@malonguwa
Copy link

@grabbou Does 64-bit version android release build included in the 0.58.x?

@malonguwa
Copy link

malonguwa commented Jan 29, 2019

@mikehardy thanks for the info~ I go through the related PR, I could not find the merged PR for this change, and also there is no any info in the 0.58 changelog, but I do see a comment in
facebook/react-native#2814 (comment)

Maybe we should wait till RN 0.59 ?

@mikehardy
Copy link

@malonguwa - ah - I see what you mean, thanks for the link to that comment. I suppose this must be related to the JSC upgrade, which will land with 0.59 and I suppose the link I sent to the code line was necessary infrastructure but doesn't meet the Play Store requirement that all the included libraries are 64-bit as well. 0.59 is coming shortly either way so not long of a wait.

@kelset kelset changed the title 0.58.2 Discussion 0.58.3 Discussion Jan 29, 2019
@mikehardy
Copy link

For anyone else upgrading, it might be worth mentioning that an npm install was not sufficient for me (it failed because the metro packager could not find bundle/unbundle.js). I had to purge node_modules then npm install, then (with some consultation of the https://github.com/pvinis/rn-diff-purge project run locally to generate diffs) everything appeared to work fine in my app

@kelset
Copy link
Member

kelset commented Jan 29, 2019

Yes I kept an eye on the issues and it seems that when migrating to 0.58 from 0.57 there is only one small native side change required -> facebook/react-native#23183 (comment)

@malonguwa
Copy link

malonguwa commented Jan 31, 2019

Is there anyone can have more info about the ScrollView breaking change in RN 0.58 ?

"Public methods of components converted to ES6 classes are no longer bound to their component instance. For ScrollView, the affected methods are setNativeProps, getScrollResponder, getScrollableNode, getInnerViewNode, scrollTo, scrollToEnd, scrollWithoutAnimationTo, and flashScrollIndicators, ............ Therefore, it is no longer safe to pass these method by reference as callbacks to functions. Auto-binding methods to component instances was a behaviour of createReactClass that we decided to not preserve when switching over to ES6 classes."

can we still use something like this ?

<ScrollView ref={"myScrollView"}>
OR
<ScrollView ref={ref => this.scrollViewRef = ref}>
and then we use this.refs.myScrollView.scrollTo() OR this.scrollViewRef.scrollTo() ? and pass the code into the child component as a prop?

Thanks a lot.

@guhungry
Copy link

guhungry commented Jan 31, 2019

@malonguwa you should use React's createRef() api.

Initialize

const scrollViewRef = React.createRef()

Render

<ScrollView ref={this.scrollViewRef}>

Using

this.scrollViewRef.current.scrollTo()

For above question you can use this.scrollViewRef.current.scrollToEnd() directly but it unsafe to do like below because scrollToEnd() won't bind to ScrollView

<Button title="Scroll Me" onPress={this.scrollViewRef.current.scrollToEnd} />

@retyui
Copy link

retyui commented Feb 1, 2019

Will these changes (Deploy Flow.js v0.89 facebook/react-native@24f8d4d#diff-d06df9030a0720f038bd694df1d1ca1f) get into the new version of react-native? We are waiting for support of React.forwardRef, React.AbstractComponent, React.Config flow.js 0.89.0

@sunnylqm
Copy link
Contributor

sunnylqm commented Feb 1, 2019

@grabbou
Copy link
Member Author

grabbou commented Feb 1, 2019 via email

@gtebbutt
Copy link

gtebbutt commented Feb 1, 2019

I've just run react-native-git-upgrade from 0.57.8, and it seems to have created a few files with underscore prefixed names: _babel.config.js, android/app/_BUCK, and android/keystores/_BUCK. I'm assuming that the existing files (without underscores) should have been updated, but I'm having trouble searching as both Google and GitHub search insist on ignoring the initial underscore!

Anyone else seen this behaviour? Is it an issue with the release, expected behaviour, or something weird in my config?

@vomchik
Copy link

vomchik commented Feb 3, 2019

Please include this PR in next patch release facebook/react-native#23276
Thanks!

@malonguwa
Copy link

malonguwa commented Feb 4, 2019

@malonguwa you should use React's createRef() api.

Initialize

const scrollViewRef = React.createRef()

Render

<ScrollView ref={this.scrollViewRef}>

Using

this.scrollViewRef.current.scrollTo()

For above question you can use this.scrollViewRef.current.scrollToEnd() directly but it unsafe to do like below because scrollToEnd() won't bind to ScrollView

<Button title="Scroll Me" onPress={this.scrollViewRef.current.scrollToEnd} />

@guhungry thanks for the detailed explanation! much appreciated it!

Do we still need to do some clean up in the ComponentWillUnMount to make the this.scrollViewRef = null or something else ?

And if this is unsafe to do this:

<Button title="Scroll Me" onPress={this.scrollViewRef.current.scrollToEnd} />
Could you mind to share what the correct way to pass this.scrollViewRef into the child component and use it in the child? I think this is a quite common usage in react native project. I can not find any more info related to this... Since this is a breaking change... then FB team could be better to provide some examples to tell us what's the new/correct way to do it.

Thanks again!

@grabbou
Copy link
Member Author

grabbou commented Feb 4, 2019

Waiting for one PR to land in master and will release a new version.

@malonguwa - I would recommend looking for an answer to your question on StackOverflow or other medium (specially in regards to your question about passing refs to children).

@forsen
Copy link

forsen commented Feb 5, 2019

It would be appreciated if facebook/react-native@728a35f could be included in next patch release

@grabbou
Copy link
Member Author

grabbou commented Feb 6, 2019

I haven't realised it yet (was facing some test failures). Will look into cherry-picking your commit too @forsen today.

@ospfranco
Copy link
Contributor

I updated from react-native 0.57 to 0.58.3 and got this same error infinitered/ignite-andross#244, it was also solved by bumping the build tools to version 28, was this intented? can it be documented on the changelog?

@kelset
Copy link
Member

kelset commented Feb 6, 2019

@ospfranco a PR would surely be appreciated ;) Thanks for pointing it out anyway, I'll add it to my notes and try to add them asap

@dulmandakh
Copy link
Contributor

@ospfranco RN exports Android tools versions and it should be used in native modules to make RN upgrades smoother. See https://github.com/react-native-community/react-native-linear-gradient/blob/master/android/build.gradle

@ospfranco
Copy link
Contributor

@kelset will do :)
@dulmandakh well, this problem was on a (semi) recently created react-native project with react-native init, I did not change anything on the gradle config until now, so some of the tooling needs to be updated independent of the libraries, or?

@dulmandakh
Copy link
Contributor

@ospfranco it seems that a native module you're using trying to use hard-coded build tools version that is different from RN. So a native module developer should try to use Android tools versions RN project exports, then use hard coded one. See the example provided in the previous comment.

@ospfranco
Copy link
Contributor

ah, so on a clean react-native project there would be no need to bump the build tools? is that what you mean? well, I really don't know which library was causing the issue, it was solved the moment I bumped the build tooling version, should I still create a PR updating the changelog?

@dulmandakh
Copy link
Contributor

with clean RN project you'll see a warning about build tools 28.0.2, but it compiles and works just fine.

@ospfranco
Copy link
Contributor

@kelset Here is the PR #85

@grabbou
Copy link
Member Author

grabbou commented Feb 7, 2019

Awesome @ospfranco - I am opening a new issue to track cherry-picks for 0.58.4

@grabbou grabbou closed this as completed Feb 7, 2019
@dulmandakh
Copy link
Contributor

dulmandakh commented Feb 7, 2019 via email

@fungilation
Copy link

Updating changelog for 0.58.4 would be great

@kelset
Copy link
Member

kelset commented Feb 7, 2019

Yeah, sorry :( we have been busy in the past few days - as always, a PR would surely help

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport request Cherry picking a change into an existing release stable Stable version
Projects
None yet
Development

No branches or pull requests