search

boardgameio / boardgame.io

State Management and Multiplayer Networking for Turn-Based Games
https://boardgame.io
MIT License
9.99k stars 704 forks source link

react-native behaves differently for multiplayer: Local() #596

Closed krema closed 4 years ago

krema commented 4 years ago

Hi,

I'm playing around with the React-Native and React TicTacToe examples. Somehow React-Native without using expo behaves differently than the example for regular web react.

The props are not filled the first time it runs. In board.js I have to initialize the following additional standard props, otherwise it will crash:

static defaultProps = {
   G: { cells: Array(9).fill(null) },
   ctx: {}
};
The crash message for example for the undefined this.props.G object

``` TypeError: undefined is not an object (evaluating '_this2.props.G.cells') This error is located at: in Board (created by WrappedBoard) in WrappedBoard (at App.js:27) in RCTView (at App.js:26) in App (at renderApplication.js:45) in RCTView (at AppContainer.js:109) in RCTView (at AppContainer.js:135) in AppContainer (at renderApplication.js:39) Board#render board.js:58:47 Board#render board.js:49:34 finishClassComponent ReactNativeRenderer-dev.js:13591:21 updateClassComponent ReactNativeRenderer-dev.js:13516:43 invokeGuardedCallbackImpl ReactNativeRenderer-dev.js:286:4 invokeGuardedCallback ReactNativeRenderer-dev.js:497:2 beginWork$$1 ReactNativeRenderer-dev.js:22028:27 performUnitOfWork ReactNativeRenderer-dev.js:20871:23 workLoopSync ReactNativeRenderer-dev.js:20848:38 performSyncWorkOnRoot ReactNativeRenderer-dev.js:20456:22 performSyncWorkOnRoot [native code]:0 runWithPriority$argument_1 ReactNativeRenderer-dev.js:5703:31 unstable_runWithPriority scheduler.development.js:818:23 flushSyncCallbackQueueImpl ReactNativeRenderer-dev.js:5698:21 flushSyncCallbackQueue ReactNativeRenderer-dev.js:5686:28 scheduleUpdateOnFiber ReactNativeRenderer-dev.js:19845:30 updateContainer ReactNativeRenderer-dev.js:23608:14 ReactNativeRenderer.render ReactNativeRenderer-dev.js:24593:19 renderApplication renderApplication.js:54:4 runnables.appKey.run AppRegistry.js:117:25 runApplication AppRegistry.js:202:4 __callFunction MessageQueue.js:425:19 __guard$argument_0 MessageQueue.js:112:6 __guard MessageQueue.js:373:10 callFunctionReturnFlushedQueue MessageQueue.js:111:4 callFunctionReturnFlushedQueue [native code]:0 ```

I couldn't find any bug in the code so far. The only line of code I find suspicious is the following. https://github.com/nicolodavis/boardgame.io/blob/c7dad766304f01fc36522816d14ed34b8cffede6/src/client/client.js#L93-L95

Why don't we initialize the state in multiplayer mode too?

nicolodavis commented 4 years ago

The client implementation returns a null until a sync has happened with the master (this is working as intended).

I think the difference you're noticing is that the web version displays a loading indicator while the React Native version does not. This should be an easy fix.

krema commented 4 years ago

You are right! Thanks! Shall I create a pull request to fix this? If so, wouldn't it make sense to rework these two implementations a little and create a base component with render props for the different use cases?

nicolodavis commented 4 years ago

Sure. Feel free to send a PR for this.

Refactoring the common logic into a base component that can be used in both React and React Native sounds good.

On Mon, Mar 30, 2020, 3:06 PM André Kremser notifications@github.com wrote:

You are right! Thanks! Shall I create a pull request to fix this? If so, wouldn't it make sense to rework these two implementations a little and create a base component with render props for the different use cases?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nicolodavis/boardgame.io/issues/596#issuecomment-605821573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZULVHZXP7QHI6KCEQ2HTRKBAGXANCNFSM4LWKLYDQ .