4 ms·

curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better ch

by platz 5y ago

curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.

aranchelk 5y ago
This is an area where I ventured far from the ordinary and wrote my own application framework. I'll eventually open source it and write an article about the process. In short: I was completely sold on the Elm architecture, but I used Haskell too long to be comfortable working without typeclasses, so I went through a couple different elm-like frameworks written for PureScript. I settled on one only to later realize what (I think) people are talking about when they say "Elm doesn't compose", which is not well articulated in that statement. I take it to mean: you can never really deal with stateful components in isolation because they have to work off of a unified global data structure. I developed some new tech that makes different tradeoffs and it got me what I wanted. I knew developing my own framework was going to add a lot of extra work: * Writing the framework (not too bad, actually) * Writing the reusable components and combinators (exactly what you'd expect) By far he hardest part has been establishing patterns and best practices working with a new and different architecture, I struggled with that for a while. I'm a strong believer in the points made in Graham's Beating the Averages (actually what brought me to HN) and in my case I'm establishing a tech stack for my current and future projects, so I believe the framework was a worthwhile investment.
- mst 5y ago
  I thought the idea was that you'd have layers of actions so you have a top level handler of some sort that would then dispatch a contained-within-the-primnary-action component-scoped action and then pull the new component data back into the global store. (apologies for the lumpy phrasing, insomnia is a pain)
  - aranchelk 5y ago
    That may be best practice, I'm not sure. Regardless, you can imagine as a result of that style of coding, any changes to the type of your components state will require at least some changes within the component, changes to one or more of those layers of action handlers, and a change to the initial/default instance of your applications model. I'm absolutely not an authority on Elm architecture, I just know that my experience doing stuff like forms with validation really sucked.
    - mst 5y ago
      I'm not sure an optimal implementation of the pattern requires onerous changes but it seems like one of those things where even if I'm right about said optimal implementation, learning how to get all the details right such that you get to that state is exceedingly non-trivial and the world seems to be divided into people who've already had the relevant "aha" moments and for whom it's now Just Obvious ... and people like us, who know just enough to blow both feet off ;)

by platz 5y ago

curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.

aranchelk 5y ago

This is an area where I ventured far from the ordinary and wrote my own application framework. I'll eventually open source it and write an article about the process. In short: I was completely sold on the Elm architecture, but I used Haskell too long to be comfortable working without typeclasses, so I went through a couple different elm-like frameworks written for PureScript. I settled on one only to later realize what (I think) people are talking about when they say "Elm doesn't compose", which is not well articulated in that statement. I take it to mean: you can never really deal with stateful components in isolation because they have to work off of a unified global data structure. I developed some new tech that makes different tradeoffs and it got me what I wanted. I knew developing my own framework was going to add a lot of extra work: * Writing the framework (not too bad, actually) * Writing the reusable components and combinators (exactly what you'd expect) By far he hardest part has been establishing patterns and best practices working with a new and different architecture, I struggled with that for a while. I'm a strong believer in the points made in Graham's Beating the Averages (actually what brought me to HN) and in my case I'm establishing a tech stack for my current and future projects, so I believe the framework was a worthwhile investment.

mst 5y ago
I thought the idea was that you'd have layers of actions so you have a top level handler of some sort that would then dispatch a contained-within-the-primnary-action component-scoped action and then pull the new component data back into the global store. (apologies for the lumpy phrasing, insomnia is a pain)
- aranchelk 5y ago
  That may be best practice, I'm not sure. Regardless, you can imagine as a result of that style of coding, any changes to the type of your components state will require at least some changes within the component, changes to one or more of those layers of action handlers, and a change to the initial/default instance of your applications model. I'm absolutely not an authority on Elm architecture, I just know that my experience doing stuff like forms with validation really sucked.
  - mst 5y ago
    I'm not sure an optimal implementation of the pattern requires onerous changes but it seems like one of those things where even if I'm right about said optimal implementation, learning how to get all the details right such that you get to that state is exceedingly non-trivial and the world seems to be divided into people who've already had the relevant "aha" moments and for whom it's now Just Obvious ... and people like us, who know just enough to blow both feet off ;)