Rename model to state.

[jorgebucaran]

Please 👍 or 👎.

[nichoth]

Those terms make no difference to me, so no need to change it.

[selfup]

Since we changed updates to actions, following the redux/Vuex semantics would be nice. Renaming to state makes sense 👍

[arturi]

Model is something from MVC frameworks to me, and I still get confused for a second when I stumble upon it in Hyperapp. Choo, Yo-yo, React/Preact all call it state, so I’m in favor of renaming for consistency.

[FlorianWendelborn]

@jbucaran I'm in favor of state since a friend of mine was confused about the difference between model and state and this terminology is one of the things he considers confusing about hyperapp.

Of course that's anecdotal, but I don't care.

[jorgebucaran]

I don't mind either, and the reason I chose model was TEA, but I also agree with some people finding model confusing since the most widespread term is state anyway.

[jorgebucaran]

Hi @SkaterDad @nichoth @cdeutmeyer!

If you have a minute, can you explain why you dislike / disapprove this notion?

[leeoniya]

i upvoted state, but if you intend to stay close to TEA, then it may be worth sticking to its terminology [1].

[1] https://guide.elm-lang.org/architecture/

[jorgebucaran]

@leeoniya You're right, but TEA also has the word update which we don't use anymore.

@dodekeract Does your friend find hyperapp confusing just because of the world model? Seems an extreme position to take just because of a word. Just curious.

[FlorianWendelborn]

@jbucaran No, mainly because of the differences to react/redux. He's currently trying to learn how to create SPAs and react/redux is the stuff he's currently attempting to learn.

[jorgebucaran]

Gotcha. Good choice anyway. Reminds me of this.

[cdeutmeyer]

I'm really fine with it either way.. I just like sticking as close as possible to Elm terminology.

[danigb]

In my mind "model" is more related to MVC and other OOP paradigms, and "state" is more connected to functional programming (where state management is made explicit instead of implicit). Mixed with the previous departure from the Elm architecture nomenclature, I'd go with "state".

[leeoniya]

my reasoning was same as @danigb

[FlorianWendelborn]

@jbucaran The community is mostly in favor of this change. Can we implement it?

Also something somewhat related: when we link to code pens we should make sure they don't use hyperapp@latest since hyperapp is currently not stable enough for that. We should always link to hyperapp@0.8.x or similar.

[jorgebucaran]

@dodekeract You are right, but latest refers to the published npm version, which is working fine AFIK.

[jorgebucaran]

Can we implement it?

Yes, let's do so after #172 is merged please.

[FlorianWendelborn]

@jbucaran Yes, it's working fine. right now. This leads to all hyperapp codepens breaking as soon as we publish breaking changes. This is especially relevant for forked codepens that inherit from our examples.

[jorgebucaran]

@dodekeract Fortunately CodePens URLs don't change, so I just need to update the code. JSFiddle URLs do change, so I'll have to rewire everything or ditching JSFiddle.

[FlorianWendelborn]

@jbucaran You don't see the problem. People fork our examples. This means they inherit this time bomb that destroys their codepens as soon as we introduce another breaking change.

[jorgebucaran]

@dodekeract Ah, you're right... 😥

[selfup]

If the codepens use specific versions (as they should) then everything will be fine 😄

[AG-Systems]

Why not just offer both versions?

[jorgebucaran]

@AG-Systems Do you mean both model and state?

I guess we could, but the idea is to come up with a clear API that is easy to teach and learn, also that would waste some bytes for no good reason.

Check out #177, we're renaming model to state in 0.8.0.

[AG-Systems]

Yes @jbucaran
Oh okay sweet