"NewAppScreen" Library and React Native default app template

[Simek]

Hope I'm posting this to the correct place. Please redirect me if I'm wrong.

Introduction

Just a simple question about react-native default app template.

The Core of It

Is there a particular reason why files creating NewAppScreen are located inside Libraries folder (react-native/Libraries/NewAppScreen) and not in app template itself?

There are basically two minor reasons why I would move those files inside app template (if possible):

• current approach cuts out the ability to "play" and experiment with already working components for the beginners,
• including NewAppScreen files will create basic structure of src folder which could help beginners with structurizing their app.

This also could be lightly linked with "Lean Core" idea, because now those example files are included in react-native codebase and are shipped with every version (when probably no one is using this library or those views in real application).

Of course I might be completely wrong or just have missed something. But if changes mentioned above are possible and wanted I can prepare suitable PR to react-native repository.

[acoates-ms]

Having the NewAppScreen components be part of the react-native package allows other platforms to replace those components without having to update the template. For instance when using react-native-windows the instructions to debug are replaced with the appropriate instructions for windows, without having to add additional .windows specific files to the template.

[kelset]

👋 there - as stated in the README and the issue template, this repo is for long-form discussions. Yours seems more a question for StackOverflow instead.

(that said, Andrew replied to you correctly so I think we can close this 👍)

[Simek]

@kelset Thank you for your response. Of course we can close this issue but I'm still not sure if this is an ideal solution with given circumstances and I'm not completely sold on whole idea of reusing core template, tailored for the mobile devices, on the different platforms especially when having this as internal library is affecting directly packages shipped on Android and iOS.

From my research react-native-windows is the only one example using this approach that I can find.
react-native-tvos is using NewAppScren components without changing them but it is already in they custom template (https://github.com/react-native-community/react-native-tvos/blob/61df2f5af46098889cdbf984832131af3093ec9d/template/App.js).
Other packages like react-native-web, react-native-macos or react-native-desktop opted out using NewAppScren or are using their own, customized templates which in general seems like more intuitive approach for me. Also I think that it's inevitable that react-native-windows will sooner or later switch to their own template.

So maybe the template should be extracted from React Native to a stand alone repository and published as separate NPM package? Will this help in a long run or just add more unnecessary complexity? I might be still confusing some fact but that's the reason I would like to discuss more about this subject.

P.S. And THB I don't like whole StackOverflow redirect idea. For years GitHub was and currently is the place where you can communicate with authors, maintainers and contributors of packages you are using. And for me StackOverflow is mostly a place to report and discuss development process and technology/library/component usage problems. That's why I have added a note at the beginning of my issue, but I'm still leaning more towards GitHub as a correct place for this discussion.

[kelset]

Hey Bartosz - on this:

P.S. And THB I don't like whole StackOverflow redirect idea. For years GitHub was and currently is the place where you can communicate with authors, maintainers and contributors of packages you are using. And for me StackOverflow is mostly a place to report and discuss development process and technology/library/component usage problems. That's why I have added a note at the begging of my issue, but I'm still leaning more towards GitHub as a correct place for this discussion.

While we have to agree to disagree on this, since you are now changing the question into more of a proposal of moving the template out of the main repo, I would suggest that maybe you open a new issue and follow the template to propose your change? I'm keen to leaving that one open and label it as discussion - but this is still question originally and since this is the policy we have for questions, I would prefer to act the same way for everyone.

[Simek]

@kelset Sorry for changing the initial purpose of this issue but it was hard, in the first place, to create proposal or even a detailed question when I had not enough knowledge and I don't know the reason behind current approach.

Even now I'm not 100% sure I have obtained all required information to comfortable create meaningful proposal or discussion without a comment to the points I have mentioned above. And I purposely have not closed this issue after first comment because I was looking for more information on the subject.

[elicwhite]

I believe these were some of the additional tradeoffs to the approaches considered:

Separate package: people would have to yarn remove a package right a way from a new project, feels gross
Files directly in the template: There are a bunch of files used in the new app screen. You’d have to delete a bunch of files to get started
Files imported from React Native: single file to change in the template, easy to start writing your project, harder to see a bunch of sample code you can tweak.

[kelset]

(ok, looks like this is becoming the actual discussion... let's reopen and move on with it)

my 2c$ on having this as separate package: since it's part of the CI jobs we run on the main repo, I'm not sure we want this to be the way

[Simek]

@TheSavior Thank you for joining discussion. You provided a set of good points for all approaches and I totally agree that using yarn remove right away will be inconvenient.

Additional I can add that currently NewAppScreen library contains 7 files (4 components, 1 static object with color scheme, 1 image and index.js just for exports) which seems not so overwhelmingly many, considering how many files can contain production-ready app.

[elicwhite]

For what it's worth, this decision weighing these options was made very recently with the new app screen: #122

I'm not super excited to be revisiting this so soon, and the likelihood we make a change here at this point feels pretty low to me unless there is a large consensus that the tradeoffs that were made previously are no longer the right balance.

[Simek]

@TheSavior Thank you for shedding more light on the topic. I was not aware of mentioned above issue and the fact that those changes and decisions are relatively fresh.

Looking from this point of view I think that some potential improvements which discussion in this issue can create are not that important for whole ecosystem to reopen big discussion about NewAppScreen, so the case is closed for me.

Thank you all for your time and effort here.

[kelset]

@FreddieMercurial how did you set the expectation that the app would work on both web and android? The documentation talks about Android and iOS: https://reactnative.dev/

Were you following some guides or something like that? I'd like to make sure that the docs don't create that confusion

[JessicaMulein]

@FreddieMercurial how did you set the expectation that the app would work on both web and android? The documentation talks about Android and iOS: https://reactnative.dev/

Were you following some guides or something like that? I'd like to make sure that the docs don't create that confusion

Went with another template that seems to achieve this...
edit: ultimately spent a day learning react and fiddling with builds and moved on for now. I'm sticking to web until I need something more complex and then I'll figure out the universal solution or write a separate app- hopefully reusing components...

[JessicaMulein]

I'm not sure my learning process has been correct. Too many outdated blog entries- and yet hard not to get "too current"