Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Author here.

> "When this field changes, I want to update this other field".

That's the problem MVC solves, and that not just a vast majority of so-called MVC frameworks (that are nothing of the sort) get fundamentally wrong, but also a lot of people talking about MVC, in particular those who want to "fix" this non-problem of MVC (see: React).

In MVC, fields never update other fields. The model also doesn't update any fields.

1. UI events update the model, and only the model

2. The model notifies the UI that it has been updated, and the UI is now inconsistent. It does not initiate an actual update, nor does send data to the UI.

3. The UI fixes the inconsistency by updating itself from the model. This can be a full update, or it can do something more clever to only update parts it knows have changed. This may be in response to an update notification or not.

No update loops. No inconsistencies (well except the temporary ones until the UI has updated itself, but those are part of the deal). Solved in the 70s.

I wrote about this here: Model Widget Controller (MWC) aka: Apple "MVC" is not MVC

https://blog.metaobject.com/2015/04/model-widget-controller-...

And here: Blackbird: A reference architecture for local-first connected mobile apps

https://blog.metaobject.com/2022/06/blackbird-simple-referen...



The update loop occurs as a result of step 3 in which the UI updates itself from the model which then, due to a combination of developer inexperience, UI framework design/complexity, or application complexity, the UI then automatically triggers updates to the model. In my experience, this was a common defect in all applications I've seen that used various MVC style frameworks or home grown MVC architectures.

In a declarative framework, while it is still technically possible, it is very rare. The current app I'm working on is one of the largest front-end apps I've worked on (multiple years of dev). We've had a single infinite loop issue reported that was trivial to fix. We have very junior UI devs compared to teams I've worked on in the past, yet our UI defect rate is incredibly low.


> The update loop occurs as a result of step 3 in which the UI updates itself from the model which then, due to a combination of developer inexperience, UI framework design/complexity, or application complexity, the UI then automatically triggers updates to the model.

In an actual MVC framework, that can't happen.

By which I mean: it cannot and does not happen as a side effect of normal processing that you need extra skill and care to avoid.

Because updates to the UI only come from the model (but pulled by the UI when it is ready) and do nothing else. Changes to the model from the UI only come from user input and only from user input.

As an example, I can't recall every having to deal with this problem in NeXTstep/AppKit/Cocoa in the last 35 years.

If this situation is something that can and does happen just as an emergent effect of normal processing and takes extra care, effort and skill to avoid, then I would argue what you have is not a real MVC framework.

You can obviously always add bugs to programs by just putting them in manually, like, abort() or while(true) {}.


Oh…and on the other hand update loops seem to be quite common in “declarative” SwiftUI.

Go figure…




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: