Playground screen UI states #33
Conversation
| .model('PlaygroundUiState', { | ||
| loading: types.maybe(Loading), | ||
| error: types.maybe(Error), | ||
| content: types.maybe(Content) |
There was a problem hiding this comment.
When would we use types.maybe() vs. types.optional()? (line 41)
There was a problem hiding this comment.
If I understand correctly, optional means that if the value is not there (i.e. persisted from last session) then it would set the default value provided as the second argument. Maybe seems like the actual nullable type (with two variants, one uses null and the other undefined to express missing value)
| @@ -1,76 +1,108 @@ | |||
| import React, { FC } from "react" | |||
| import * as React from "react" | |||
There was a problem hiding this comment.
This is fine but since we have allowSyntheticDefaultImports: true in tsconfig.json we don't need this change.
I actually found that this wildcard import is best practise (they exist in RN?) 😱 and shared another interesting guidelines below
facebook/react#18102
https://github.com/facebook/react-native-website/blob/main/STYLEGUIDE.md
There was a problem hiding this comment.
There's a difference in behaviour (at least on my VSCode so it might be my config) with autocomplete. When I start writing a function from react such as useEffect then autocomplete behaves differently depending on the import type:
In case of import * as React ... autocomplete will update the function call to React.useEffect
In case of import React ... the autocomplete will add another import {useEffect} and not change the function call
The import * is definitely more verbose but at least for now it makes it easier for me to understand where the code comes from even if it is probably not the correct JS approach
| import { | ||
| Text, Screen | ||
| } from "../components" | ||
| import { isRTL } from "../i18n" |
There was a problem hiding this comment.
This is fine to go as its not really used, but incase it comes up again - this returns if the current device language direction is Right-To-Left. This is part of the I18nManager localization lib, which supports multiple languages including Arabic.
There was a problem hiding this comment.
it's weird that this would need to be in the feature code though
| } | ||
| <View style={[$bottomContainer, insets]}> | ||
| <Text tx="playgroundScreen.exciting" size="md" /> | ||
| <Text text={`Value is: ${content.number}`} size="md" /> |
There was a problem hiding this comment.
@juankysoriano had a question in the nav PR I didn't get to - but this shows off the difference between tx=screen.stringName and text={String Literal}. Hope this helps
| } | ||
| function StateComponent(insets, uiState, onResetClicked) { | ||
| const { loading, error, content } = uiState | ||
| if (loading) { |
There was a problem hiding this comment.
Can we make this a Switch Case operator?
There was a problem hiding this comment.
I'm not sure how to write a switch like that, these are separate properties of the uiState object where each can be either there or undefined
| const $bottomContainerInsets = useSafeAreaInsetsStyle(["bottom"]) | ||
| export const PlaygroundScreen: React.FC<PlaygroundScreenProps> = observer((props) => { | ||
| const $bottomContainerInsets = useSafeAreaInsetsStyle(["bottom"]) | ||
| const { playgroundStore } = useStores() |
There was a problem hiding this comment.
🎉 Nice work
Leaving some extra info for others: https://mobx.js.org/defining-data-stores.html
The main responsibility of stores is to move logic and state out of your components into a standalone testable unit that can be used in both frontend and backend JavaScript.
There was a problem hiding this comment.
Left a couple optional comments, LGTM
Did you test?
manually only, no idea how to write tests here yet
yet 😈 Looks like React Native comes with Jest for testing by default, which I've noted and we'll explore together https://jestjs.io/
|
we can change/refactor code to address any other comments in next PRs |
Short Description
Adds UI states to the playground screen
What changes in the code?
The main goal was to learn how to define custom stores and data types with
mobx-state-treelibrary.Now there is a loading state that is followed by a content with auto-incremented number. When the number reaches 30 and error is shown. There is also a button to reset the counter. This should give us enough of a base to start adding some real code that fetches some data from somewhere and displays it on the screen.
Did you test?
manually only, no idea how to write tests here yet
paired with
@Frankie-Boy at the beginning where nothing made sense