6 ms·

After spending 3 years writing iOS interfaces solely in UIKit, my first work moving to cloud app development was solely in React/Om. It was like riding a bicycl

After spending 3 years writing iOS interfaces solely in UIKit, my first work moving to cloud app development was solely in React/Om. It was like riding a bicycle for the first time. Amazing how far you could go in UI work with such (relatively) little effort.

LiweiZ 11y ago
Do you think it's a good idea to write React components with APIs somewhat mimic UIKit, such as UIView? Or is that possible? I'm new to web app. Thanks in advance.
- hellofunk 11y ago
  UIKit is a very OO framework. React is not. I'd recommend thinking about UI in a new way when moving to React.
  - LiweiZ 11y ago
    Thanks for your advice. One of the reasons that make me think this way is it seems there are some attempts to pick up inline CSS. IME, I believe object-based (or thing-based, it does not have to be strictly related to one paradigm) system is easier to understand when I work on UI. I'm probably biased and lack of enough knowledge and experience to see it through. This is just my current guess.
    - RussianCow 11y ago
      OO is easier to grasp initially, but you have to keep track of lots of state, and that gets really hairy really quickly. The functional approach requires more forethought, but there's much less room for error because you aren't manually moving state around your application. It's a totally different way of thinking about UI, but it's worth it for the productivity you gain in the long run, in my opinion.
      - LiweiZ 11y ago
        Yes, states always went messy when I made a visual module a bit complex (well, more than 50% was due to my unpolished skills though). The functional approach is better. My main mind-barrier as mentioned in the rely to hellofunk is not able to manipulate appearance through JS API. Perhaps I should stop thinking about it and just keep writing till I get used to it.
    - hellofunk 11y ago
      The React model of UI development is much much easier to work in than an OO model of UI. There are fewer wires between objects (often none at all), nearly zero state in each "object" or UI component (or none at all), no callbacks, just mostly one-way declarative setup. Apple should (and is) giving it some attention. Many former Apple UIKit developers as well as those working on things like ReactiveCocoa (which is a different paradigm) are enticed by what Facebook has done with the React paradigm.
      - LiweiZ 11y ago
        I agree with you. I did not try ReactiveCocoa since I spent time on Swift instead. But I know the react way is way easier to manage the states all over the place. Any idea on the inline-CSS thing? Is operating directly on JS a better way to go? I guess I'm too used to doing things like UIView.alpha = 0.4 to manipulate the appearance of an visual object :) Thanks for being patient of answering my silly questions.
gagege 11y ago
You can totally do pure UIViewControllers with Swift. Just initialize them with all the data they need and give them callbacks (or "handlers" if you want to call them that) for every UI control. Keep a reference to your UINavigationController somewhere outside (in AppDelegate? Hopefully not, but you could :p) any of the UIViewControllers, and use pushViewController(screenYouWantToShow(dataToPassToScreen, callback1, callback2)) to move between views. If you want to "edit" the previous screen in the stack you just build a new version of the screen you want to "edit" then remove old one from the UINavigationView.viewControllers array and insert the new one. Then popViewControllerAnimated() back to it. It works very well. Making iOS apps this way has been a dream come true for me.
- thewarrior 11y ago
  Handlers for every UI control ? Could you elaborate on that part ? Does this approach scale well ? Have you done large apps ? FB has an open source ComponentKit Framework.
  - gagege 11y ago
    "Handlers for every UI control?" Sure, for every piece of the UI that commits a change to the model, such as a save button, you need a callback to pass the updated model to. You pass a "movie" object and a "saveMovie()" callback into a screen that allows you to edit the details of a movie. You edit the fields then click "save". The code that runs when the "save" button is clicked builds a new movie object then masses the new movie object to the the callback, like this "saveMovie(editedMovie)". The "saveMovie()" callback makes the API calls, database calls, etc, and the movie editing screen doesn't need to to anything else after that, and inside "saveMovie()" you can push a new screen, pop back to the previous one, or whatever. Does that make sense? "Does this approach scale well?" I don't see how it could be much worse than making API calls from UIViewControllers. If you do this, you're instantiating new UIViewControllers more often, so if you're loading a bunch of images on a certain view you may want to hang on to a reference to that particular view instead of building a new one each time. But, in my experience, the code ends up being a LOT cleaner than if you treat your UIViewControllers as mutable objects. So from an architecture and maintainability standpoint, it scales really well.

LiweiZ 11y ago

Do you think it's a good idea to write React components with APIs somewhat mimic UIKit, such as UIView? Or is that possible? I'm new to web app. Thanks in advance.

hellofunk 11y ago
UIKit is a very OO framework. React is not. I'd recommend thinking about UI in a new way when moving to React.
- LiweiZ 11y ago
  Thanks for your advice. One of the reasons that make me think this way is it seems there are some attempts to pick up inline CSS. IME, I believe object-based (or thing-based, it does not have to be strictly related to one paradigm) system is easier to understand when I work on UI. I'm probably biased and lack of enough knowledge and experience to see it through. This is just my current guess.
  - RussianCow 11y ago
    OO is easier to grasp initially, but you have to keep track of lots of state, and that gets really hairy really quickly. The functional approach requires more forethought, but there's much less room for error because you aren't manually moving state around your application. It's a totally different way of thinking about UI, but it's worth it for the productivity you gain in the long run, in my opinion.
    - LiweiZ 11y ago
      Yes, states always went messy when I made a visual module a bit complex (well, more than 50% was due to my unpolished skills though). The functional approach is better. My main mind-barrier as mentioned in the rely to hellofunk is not able to manipulate appearance through JS API. Perhaps I should stop thinking about it and just keep writing till I get used to it.
  - hellofunk 11y ago
    The React model of UI development is much much easier to work in than an OO model of UI. There are fewer wires between objects (often none at all), nearly zero state in each "object" or UI component (or none at all), no callbacks, just mostly one-way declarative setup. Apple should (and is) giving it some attention. Many former Apple UIKit developers as well as those working on things like ReactiveCocoa (which is a different paradigm) are enticed by what Facebook has done with the React paradigm.
    - LiweiZ 11y ago
      I agree with you. I did not try ReactiveCocoa since I spent time on Swift instead. But I know the react way is way easier to manage the states all over the place. Any idea on the inline-CSS thing? Is operating directly on JS a better way to go? I guess I'm too used to doing things like UIView.alpha = 0.4 to manipulate the appearance of an visual object :) Thanks for being patient of answering my silly questions.

gagege 11y ago

You can totally do pure UIViewControllers with Swift. Just initialize them with all the data they need and give them callbacks (or "handlers" if you want to call them that) for every UI control. Keep a reference to your UINavigationController somewhere outside (in AppDelegate? Hopefully not, but you could :p) any of the UIViewControllers, and use pushViewController(screenYouWantToShow(dataToPassToScreen, callback1, callback2)) to move between views. If you want to "edit" the previous screen in the stack you just build a new version of the screen you want to "edit" then remove old one from the UINavigationView.viewControllers array and insert the new one. Then popViewControllerAnimated() back to it. It works very well. Making iOS apps this way has been a dream come true for me.

thewarrior 11y ago
Handlers for every UI control ? Could you elaborate on that part ? Does this approach scale well ? Have you done large apps ? FB has an open source ComponentKit Framework.
- gagege 11y ago
  "Handlers for every UI control?" Sure, for every piece of the UI that commits a change to the model, such as a save button, you need a callback to pass the updated model to. You pass a "movie" object and a "saveMovie()" callback into a screen that allows you to edit the details of a movie. You edit the fields then click "save". The code that runs when the "save" button is clicked builds a new movie object then masses the new movie object to the the callback, like this "saveMovie(editedMovie)". The "saveMovie()" callback makes the API calls, database calls, etc, and the movie editing screen doesn't need to to anything else after that, and inside "saveMovie()" you can push a new screen, pop back to the previous one, or whatever. Does that make sense? "Does this approach scale well?" I don't see how it could be much worse than making API calls from UIViewControllers. If you do this, you're instantiating new UIViewControllers more often, so if you're loading a bunch of images on a certain view you may want to hang on to a reference to that particular view instead of building a new one each time. But, in my experience, the code ends up being a LOT cleaner than if you treat your UIViewControllers as mutable objects. So from an architecture and maintainability standpoint, it scales really well.