38 ms·

I started a project in React Native a few months ago, then I left it for a couple weeks, then when I came back to it, I did the usual chore of updating librarie

by hasenj 10y ago

I started a project in React Native a few months ago, then I left it for a couple weeks, then when I came back to it, I did the usual chore of updating libraries, and found that I could no longer compile/run the project. Purged and re created my npm_modules folder to no avail. Things kept getting worse and I simply have no clue what is going on. Started a fresh RN project and even that would not run. I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.

lohengramm 10y ago
I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.
- spicyj 10y ago
  Were you using many other libraries? We try to keep React itself pretty simple and recommend you start with that.
  - lohengramm 10y ago
    I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937. I know I am just complaining like a grouchy old man and not really helping understand and solve the problem, but that's what I can do right now. I would say that maybe we are building too modular software and the complexity of glueing everything together is becoming a problem? I feel like the existance of several "react + this + that" boilerplates indicates something. I can also be wrong and everything is OK and I am problematizing.
    - hasenj 10y ago
      I purposely avoid all this mess. The only thing in my "build stack" was TypeScript and a small custom script I wrote myself to assemble things together. Before I joined that project they were using yoeman and angular and a bunch of other useless crap. I got rid of all of it.
    - spicyj 10y ago
      That's helpful, thanks.
    - danabramov 10y ago
      Have you tried Create React App? We made it so that you don’t need to deal with any of that. https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app
- hasenj 10y ago
  I don't remember struggling that much with React itself in terms of untraceable compilation problems. But then again, I already have a lot of experience with normal web development, so I already know what's under the cover, more or less. Whereas with mobile, I have none, and I felt that RN was supposed to let me do mobile dev despite not knowing what goes on under the covers.
jesseruder 10y ago
Hey I work on Expo - this is one of the big pain points we're trying to improve. Since Expo is responsible for the native code in these apps we can do the work of keeping all the libraries up to date. You're just responsible for updating the JS code, which normally has minimal breaking changes. Many people have been able to update versions by only changing their dependencies in package.json.
- hasenj 10y ago
  It's not just that. I also need plugins for basic functionality that RN does not provide it out of the box, like playing audio, accessing the file system, reading sqlite databases, etc. "Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on. I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries. But like I said, I just have no idea what's going on. If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.
  - jesseruder 10y ago
    Yes a lot of times the issue is that libraries only support certain version of React Native, so for certain sets of libraries there are no versions of React Native compatible with all of them. Expo has audio (https://docs.expo.io/versions/latest/sdk/audio.html https://docs.expo.io/versions/latest/sdk/audio.html), file system (https://docs.expo.io/versions/latest/sdk/asset.html https://docs.expo.io/versions/latest/sdk/asset.html), and other APIs built in (https://docs.expo.io/versions/latest/sdk/index.html https://docs.expo.io/versions/latest/sdk/index.html). We don't have sqlite right now but are actively working on it! The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.
    - 10y ago
digitalmaster 10y ago
I've been an early adopter of react native for a long time.. and this was exactly my experience... it's very demoralizing and why i switched to exponent and try as hard as possible to do all I can with just JS (without detaching project form expo). So far it's been amazing!

by hasenj 10y ago

lohengramm 10y ago

I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.

spicyj 10y ago
Were you using many other libraries? We try to keep React itself pretty simple and recommend you start with that.
- lohengramm 10y ago
  I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937. I know I am just complaining like a grouchy old man and not really helping understand and solve the problem, but that's what I can do right now. I would say that maybe we are building too modular software and the complexity of glueing everything together is becoming a problem? I feel like the existance of several "react + this + that" boilerplates indicates something. I can also be wrong and everything is OK and I am problematizing.
  - hasenj 10y ago
    I purposely avoid all this mess. The only thing in my "build stack" was TypeScript and a small custom script I wrote myself to assemble things together. Before I joined that project they were using yoeman and angular and a bunch of other useless crap. I got rid of all of it.
  - spicyj 10y ago
    That's helpful, thanks.
  - danabramov 10y ago
    Have you tried Create React App? We made it so that you don’t need to deal with any of that. https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app
hasenj 10y ago
I don't remember struggling that much with React itself in terms of untraceable compilation problems. But then again, I already have a lot of experience with normal web development, so I already know what's under the cover, more or less. Whereas with mobile, I have none, and I felt that RN was supposed to let me do mobile dev despite not knowing what goes on under the covers.

jesseruder 10y ago

Hey I work on Expo - this is one of the big pain points we're trying to improve. Since Expo is responsible for the native code in these apps we can do the work of keeping all the libraries up to date. You're just responsible for updating the JS code, which normally has minimal breaking changes. Many people have been able to update versions by only changing their dependencies in package.json.

hasenj 10y ago
It's not just that. I also need plugins for basic functionality that RN does not provide it out of the box, like playing audio, accessing the file system, reading sqlite databases, etc. "Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on. I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries. But like I said, I just have no idea what's going on. If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.
- jesseruder 10y ago
  Yes a lot of times the issue is that libraries only support certain version of React Native, so for certain sets of libraries there are no versions of React Native compatible with all of them. Expo has audio (https://docs.expo.io/versions/latest/sdk/audio.html https://docs.expo.io/versions/latest/sdk/audio.html), file system (https://docs.expo.io/versions/latest/sdk/asset.html https://docs.expo.io/versions/latest/sdk/asset.html), and other APIs built in (https://docs.expo.io/versions/latest/sdk/index.html https://docs.expo.io/versions/latest/sdk/index.html). We don't have sqlite right now but are actively working on it! The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.
  - 10y ago

digitalmaster 10y ago

I've been an early adopter of react native for a long time.. and this was exactly my experience... it's very demoralizing and why i switched to exponent and try as hard as possible to do all I can with just JS (without detaching project form expo). So far it's been amazing!