Does that automatically run against every PR? What mitigations did you have to put in place for Google security to allow running untrusted code from PRs on internal CI?
Disclaimer, I’m one of the EMs for React at Meta, and spent many years directly working on React Native.
> It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api.
Yet.
React Server Components as a pattern and paradigm are not unique to web sites and the team has designed it with React Native in mind. We are just starting with web to flesh out the ideas and work with the ecosystem first.
RSCs (and SSR) are both technologies totally possible to use with RN, theoretically, we just haven’t built out the support yet. At the most basic, instead of rendering to HTML that the server sends down, it would render to commands that React Native’s native code would execute. Similar to the distinction between React DOM and React Native.
So we are excited about these technologies even though they are currently web only, and it’ll still be a while until we bring them to React Native.
Since the platform doesn’t provide shadow support, React Native can’t provide that support on Android either. React Native’s shadow API works for the platforms that do support it, like iOS, Windows, and macOS.
I'm on the React Native team and if this is still an issue, we still want to know about it. As others said, the icebox occurs automatically after a period of inactivity.
From quick glance, this seems more related to Metro, the packager that React Native uses. It was split out from the React Native repo and the team working on it is extremely receptive. I'd recommend opening a new issue on https://github.com/facebook/metro and linking to the issue in the RN repo.
People (including a team member of mine) are still commenting on https://github.com/facebook/react-native/issues/8475 which has been iceboxed and never re-opened. Same problem, which made the RN team seem very unreceptive.
Indeed, I think it's worth a shot to see if the metro team is more receptive. Thanks for the suggestion.
He has commented below that the 'front end is GWT, back end is Java servlets. Database was originally MySQL but switched to Prevayler for performance reasons.'
I have built a similar tool that is also an HTML5 / Canvas collaborative drawing app which uses Google Drive for storage and has no server code beyond that. It works offline (and syncs up with collaborators when you come online) and runs in Chrome, Firefox, Safari, iOS, and Android and supports touch. http://thesavior.github.io/draw/
This is another HTML5 / Canvas collaborative drawing app that I built which uses Google Drive for storage and thus runs completely locally. Works offline and runs in Chrome, Firefox, Safari, iOS, and Android and supports touch. http://thesavior.github.io/draw/
The one thing my wife (a math teacher) has always been craving is a video solution for these - that is, write equations or annotate a document on our android tablet while she narrates, then upload the video to YouTube. Last I checked there wasn't a good offering on the play store for this.
I do that with Screenflow and a Wacom Intuos Pro, and that's a very simple set up.
I understand it's not a solution for the Android tablet, but I also thought I wanted to draw on a tablet and I've been happy with my set up - I can sit up and look forward and it feels better that way, than it would if I looked down towards my drawing hand and the tablet screen.
Just a thought. I'm one of those people who would never buy a Wacom Cintiq because I see the decoupling of "object to draw on" and "object to look at while drawing" as an incredible advantage.
