Hacker News Reader

Comment by escherize | Hacker News Reader

I've noticed the f(data) = view paradigm dominate the clojurescript landscape ever since om and reagent[1]. There's also a library that literally uses function calls and parameters for every piece of UI called re-frame[2] (which also has a badass readme).

Using pure functions to compose a UI along with keeping all the data in one place have been a huge win for our project for a few reasons.

1. All it takes to debug what a handler is doing is what effect it has on the DB. Our handler functions are also mostly pure functions which take the current-db as a parameter.

2. We can serialize the state to local storage (or a string) and reload it from local storage (or a string).

3. Using the repl, we can investigate the state of the application while it's running.

[1] http://reagent-project.github.io [2] https://github.com/Day8/re-frame/

View on HN

It is virtually impossible to go back to a non unidirectional ui without feeling gross and disgusted. Working on a major angular project after doing some cljs with react feels like a decades step back - back to a horrible jsf like two way data binding disaster. Where is my state? Where is my api? Why did x put y here?

If it doesn't take hold this generation, it will definitely cycle back decades from now as the dominant way to structure ui code.

Between unidirectional flows and observables (or maybe some other async primitive) UI is getting very interesting these days. Personally I prefer rx to core.async. Core async just looks too awkward and low-level for me. RX I got immediately - a promise for a stream. Great stuff.

Have you messed with Cycle.js? They just hit 1.0 recently and use rx extensively, it's an absolute blast to use

It's number one my list of projects to check out! Looking forward to it.

Are you using this in production? Or for a side project? How and where are you using it?

Thanks for any info.

Just on a couple of rinky dink side projects with babel & webpack! Nothing major

and of course don't miss out cycle-react, which is based on rxjs and cycle.

Clicked through to this, spent a bit of time going huh? But it very gradually started to come into focus. I definitely going to give it a whirl for a few small in house webapps - thanks!

> Working on a major angular project after doing some cljs with react feels like a decades step back

It looked for me that way even before I started learning about React.

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.

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.

UIKit is a very OO framework. React is not. I'd recommend thinking about UI in a new way when moving to React.

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.

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.

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.

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.

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.

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.

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.

"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.

I tried this approach with my current Swift project, but I found that it doesn't scale to a certain level of complexity. A ton of the UIKit APIs are naturally stateful, so you end up having to work around them in weird ways. Animation is particularly hard when your view controllers are pure. The solution I opted for was to instead create a unidirectional data flow and just "refresh" the state of the VC every time it gets passed different data. This way, you get most of the benefits of one-way data flow and the state of your VCs is (somewhat) pure, but you can easily drop down and use the UIKit APIs as needed.

I agree. UIKit is very OO. The style of UI development exemplified by React/Om/Reagent/Clojurescript, etc, is totally different.

I see what you mean. I'd probably run into issues if I was doing a lot of transitions animated transitions and interactions. With my method nothing is really stopping you from creating a VC that has a public refresh function though. It would just have to break the pattern of ask the others a little bit.

> Have you done large apps ?

At work we're at 10k loc which isn't huge but it's fairly large for a clojurescript app. Middleware on event handlers is a great abstraction. It's only been a few weeks since the refactor and there are only three of us on the team but I'm not foreseeing any scaling problems. The only changes we made are about 20 middlewares and namespacing our event keywords. We experimented with a forked version of the framework and running multiple re-frame apps nested inside each other but it wound up not being worth the effort.

The only scaling hazard I know of is that re-frame has an internal global atom so that might cause a problem if you're mixing multiple re-frame apps on a single page but it doesn't affect us and reworking the framework to not use a global isn't too difficult.

having worked on a number of iOS apps (everywhere from 5k loc to 80k loc), i have literally never seen anyone work any other way -- you just put `[self renderView:model]` on your controllers and it's a pure function which sets up the state such that the system `layoutSubviews` call is also pure function.

i havent seen that "build a new version of the previous screen" tho, at least not the way you describe -- most of the time you just rely on `viewWillAppear` calling `renderView:model`, and `viewWillAppear` gets called on `popViewController` by default.

The idea is to get away from callbacks altogether. That is the idea of FB React and Om/Reagent. What you describe is not at all the paradigm for UI development I'm talking about.

I understand that, I wasn't saying it was exactly the same. I do think that what I'm doing is better than what iOS tutorials usually teach you to do though.

While looking over a recently presented slidedeck, I came across this slide:

https://speakerdeck.com/chantastic/inline-styles-react-europ...

In that moment, I was genuinely taken aback to realise that by using clojurescript and reagent, I was operating in what some regarded as the future. I knew it already, of course, but that moment pushed it home. Nice!

re-frame is pretty handy too. (But I'm the author, so on that point I'm pretty biased).

Yes! Re-Frame is fantastic, and a core part of a major project I am working on. In this spirit I am also really looking forward to Om Next.

I agree that re-frame is awesome. I also love reagent and figwheel.

Are you planning to incorporate datascript or datomic at all in your projects?

I've been using re-frame for about a week now and it's awesome. Super simple to get into - building an interactive ui has never been so easy.

Reply on news.ycombinator.com