3 ms·

> Your final paragraph hints at the kind of engineering that inevitably begins to appear as a workaround to solving the wrong problem in the first place. All of

by philh 6y ago

> Your final paragraph hints at the kind of engineering that inevitably begins to appear as a workaround to solving the wrong problem in the first place. All of it is extra complexity that doesn't need to exist at all. I agree it's extra complexity, and it's not strictly necessary. But it's not that much extra, and it doesn't affect pages that don't need it, which in the app I work on, most don't. (Whereas if all your pages take a top-level model, and return a top-level message, they all need to deal with that even if they don't need it.) > Does prior experience with bad surprises in Elm give you this intuition? Or is it from experience from a language like JavaScript where global mutable state is indeed something to be wary of? Not specifically Elm, I've only written it in one app. But I'm imagining bugs where a page mutates its state in ways that satisfy some invariant, and then that invariant is violated and no one can work out how it happens. Turns out some other page is editing its state, in ways that probably made sense at the time. (Granted the debugger will probably help, but... I dunno, I'd rather just not have to.) I'm not convinced large Elm apps don't have problems like this. And saying "no, if you want to communicate with another page, you have to do it through this specific mechanism" seems like a fine way of avoiding it.

pyrale 6y ago
> Turns out some other page is editing its state The solution to this particular problem is to stop thinking in terms of page. Which page you're on is only a matter of view, and maybe a minimal amount of view-related model. Most of your model data should be related to your application logic, not to a specific page or component. Separating your model logic and your view logic helps a lot to avoid having this problem, because your model logic becomes agnostic to what page modifies it.
- philh 6y ago
  I've never tried it your way, so maybe I'm missing something here. But thinking in terms of pages seems like a very useful abstraction to me. I can't keep the whole application state in my head at once, so I want to be able to look at a small part of the app and know that I don't need to think about anything else right now. (It maybe won't be "literally just this page", but "this page plus a small number of well defined mechanisms for bringing data in and out of it".) I wouldn't want to give that up, and I don't know how I'd split the state if not by page (or at least something similar, like "groups of closely related pages"). If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look.
  - yakshaving_jgt 6y ago
    > If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look. I don't mean this sarcastically (hard to convey tone in written form), but is this genuinely something you have encountered with Elm in practice? Even with the time-travelling debugger?
    - philh 6y ago
      No. Like I said, I've only worked on one Elm app, and that one doesn't let model logic be modified by any page (with some well-defined exceptions). But it's what I'd expect to sneak in if we hadn't architectured it to forbid that kind of thing. I agree that the time-travel debugger would help, but... I guess, even if that makes it less costly, I'm not seeing the benefits.
  - pyrale 6y ago
    You can think of it as an API. If your API is called, should it work differently depending on whether the request came from a browser or from a terminal curl? Probably not. Similarly, if you have a message that, calls for your model to be changed (for instance, adding a product to the cart). That message describes cart logic. The product could be added directly from the product page, or the frontpage, or from a suggestion in another product page. It is probably not relevant to the cart how exactly the product came to be added. Not all the model is like that. There is a subset of the model which exists only to describe the state of the view. But, usually, a significant part of the model is dedicated to page-independent data. > I want to be able to look at a small part of the app In my app, the small part of the app I'm going to look at is a single feature which may be used in multiple pages. It is easier for me to keep a consistent behaviour if that feature is independent from the view.
    - philh 6y ago
      Fair enough. I get the sense we're working on fairly different apps. It's also possible that if the app I'm working on were structured differently, we'd have done things more like the way you're doing things. I'm getting vague thoughts in my head along those lines, which I'll have to let ruminate and see if they go anywhere.

by philh 6y ago

pyrale 6y ago

> Turns out some other page is editing its state The solution to this particular problem is to stop thinking in terms of page. Which page you're on is only a matter of view, and maybe a minimal amount of view-related model. Most of your model data should be related to your application logic, not to a specific page or component. Separating your model logic and your view logic helps a lot to avoid having this problem, because your model logic becomes agnostic to what page modifies it.

philh 6y ago
I've never tried it your way, so maybe I'm missing something here. But thinking in terms of pages seems like a very useful abstraction to me. I can't keep the whole application state in my head at once, so I want to be able to look at a small part of the app and know that I don't need to think about anything else right now. (It maybe won't be "literally just this page", but "this page plus a small number of well defined mechanisms for bringing data in and out of it".) I wouldn't want to give that up, and I don't know how I'd split the state if not by page (or at least something similar, like "groups of closely related pages"). If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look.
- yakshaving_jgt 6y ago
  > If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look. I don't mean this sarcastically (hard to convey tone in written form), but is this genuinely something you have encountered with Elm in practice? Even with the time-travelling debugger?
  - philh 6y ago
    No. Like I said, I've only worked on one Elm app, and that one doesn't let model logic be modified by any page (with some well-defined exceptions). But it's what I'd expect to sneak in if we hadn't architectured it to forbid that kind of thing. I agree that the time-travel debugger would help, but... I guess, even if that makes it less costly, I'm not seeing the benefits.
- pyrale 6y ago
  You can think of it as an API. If your API is called, should it work differently depending on whether the request came from a browser or from a terminal curl? Probably not. Similarly, if you have a message that, calls for your model to be changed (for instance, adding a product to the cart). That message describes cart logic. The product could be added directly from the product page, or the frontpage, or from a suggestion in another product page. It is probably not relevant to the cart how exactly the product came to be added. Not all the model is like that. There is a subset of the model which exists only to describe the state of the view. But, usually, a significant part of the model is dedicated to page-independent data. > I want to be able to look at a small part of the app In my app, the small part of the app I'm going to look at is a single feature which may be used in multiple pages. It is easier for me to keep a consistent behaviour if that feature is independent from the view.
  - philh 6y ago
    Fair enough. I get the sense we're working on fairly different apps. It's also possible that if the app I'm working on were structured differently, we'd have done things more like the way you're doing things. I'm getting vague thoughts in my head along those lines, which I'll have to let ruminate and see if they go anywhere.