[slack] <janbiedermann> I would like to introduce General Plan :general: for :react: Native :fbmetro: :watchman: and :electron: Support:
✅ gradually integrate :react: native support for environment detection on_mobile? on_ios?
• support several implementation strategies:
- web first, mobile second: map them all via React::Components::Elements to Text and others with proper styling or some other appropriate component. (i did that mapping for the demo)
- mobile first, web second: https://github.com/necolas/react-native-web - making the react native components available to the web
- mobile + web: https://github.com/react-native-elements/react-native-elements , looks like there equal in weight
and at the same time leaves another question open: What about regular components that use React.createElement('div')?
Maybe they want to emphasize the fact, that there is no DOM. But well, for most cases it does not matter, at least in :isomorfeus: . If the DOM is used, well, DOOM is spelled very close to DOM anyway.
✅ figure out event handling in :react: native: same as react web technically, just a small set of events, mapping to web events seems logic, can be done in the prop conversion code:
•on_press <-> on_click, on_change_text <-> on_change, on_submit_text <-> on_blur(super easy, but check all possible events)
✅ figure out a :isomorfeus: compatible way to boot the app: figured it out 🙂 in my experimental app. Easy to integrate.
✅ figure out a way to handle react -router :router:: figured it out, works just the same as for web, very nice 😃
• figure out how to support react-jss: React native has its own Styling, very similar to ReactJss, however styling is limited. But it is possible to write styles for mobile + web. Theming does not seem to be available though. Needs some experimentation, maybe the react jss code works. If the theming code works that would be enough. If not, it will be required to adapt LucidComponents accordingly. (react-native-elements has theming, maybe use code from there)
✅ 📵 material-ui :mui: is not supported.
• map html elements (react-native-elements has h1...h4, maybe use code from there)
✅ svg https://github.com/react-native-community/react-native-svg and canvas https://github.com/iddan/react-native-canvas support , needs mapping
✅ server communication/transport: Websockets work just the same, server must be explicitly specified though, localhost may be device local, but:
• cookies dont work, so authentication must use a separate way, no problem here.
• syncing of data
• persistent data store (also useful for web): https://github.com/react-native-community/async-storage, https://developer.mozilla.org/en-US/docs/Web/API/Storage, i dentical API, :isomorfeus: just needs to provide a wrapper for both.
• run specs in native (with isomorfeus-puppetmaster, which currently uses puppeteer, but may use testcafe in the future)
• Wrap non Component React Native API for Ruby
✅ debugging works, js wise, choosing debug from dev menu of simulator, opens chrome devtools for remote debugging, nice. opal-devtools don't work with this, would be nice to get them working too. Not sure if possible.
✅ get hot reloading with metro :fbmetro: and watchman :watchman: working
The goal of all of this is, to create native apps with the least effort from :isomorfeus: users point of view. The user creates the web app and, maybe with a few ifs added, it will just work on native. Or the other way around.
[slack] <janbiedermann> Also, as i am working on :isomorfeus: pro, getting the subscription agreement ready, i noticed it is a lot of effort to get things setup for pro, with separate repos, code interaction and the agreement text and bla bla bla ....
So, considering the current situation of the world and the main reason :isomorfeus: exists: EMPOWERMENT, i decided to give up on :isomorfeus: PRO and instead make PRO part of standard :isomorfeus: and all under MIT License of course.
Maximum EMPOWERMENT for EVERYBODY.
This is way less trouble for me to get things rolling, set up etc.
I still offer professional consulting, training, support for :isomorfeus:
But i consider to replace iodine with agoo, but need to test first
As :isomorfeus: requires redis anyway now, no need to stick with iodine.
The reason for iodine was to keep setup simple.
Agoo requires redis for pubsub, for iodine redis is optional for pubsub.
If agoo is in fact more stable, i will drop iodine support, but then :redis: will be a requirement.
[slack] <janbiedermann> upcoming i-react release allows for method_ref to pass args. Thats useful for event handlers, to pass additional args based on context.
Example:
```def my_handler(event, info, arg)
puts arg
end
render do
DIV(on_click: method_ref(:my_handler, "first DIV"))
DIV(on_click: method_ref(:my_handler, "second DIV"))
end```
I am able to run the isomorfeus-website project locally but creating a new project gives me this error:
18:03:54 web.1 | ERROR: Iodine caught an unprotected exception - RuntimeError: Isomorfeus in development on Server:
18:03:54 web.1 | Server Side Rendering: Failed loading asset http://localhost:3036/assets/web_ssr.js from webpack dev server, asset is not javascript. Did the webpack build succeed?
[slack] <janbiedermann> @Diego i just remembered whats the issue, i think, did not have time to test yet. The default asset name for SSR changed because of the preparation for React Native, in your project root, the your_app.rb roda app, there is a mount_component method call, that needs a param at the end. I think you need to add 'application_ssr.js'.
The default changed to 'web_ssr.js', but that change i think is so far only in i-react, which is a bit ahead of :isomorfeus: zeta25
[slack] <frédéric ZINGG> @janbiedermann I'm trying to introduce the GSAP animation ibrary (https://greensock.com/) into the isomorfeus-website
On their Helloworls youtube video (https://www.youtube.com/watch?v=znVi89_gazE) they talk about : "React useEffect Hook"
I guess it is easy to transpose that sor of REACT useEffect hook with :isomorfeus: ?
https://medium.com/trabe/react-useeffect-hook-44d8aa7cccd0