Hyperapp: Force model to be object and always be immutable?

[tunnckoCore]

@jbucaran what you think about the model to be object and freeze it, using Object.freeze or deep-freeze?

[jorgebucaran]

@tunnckoCore What's the advantage?

[jorgebucaran]

what you think about the model to be object

choo does this IIRC. HyperApp is more flexible allowing the model to be a string, number, array or object.

[tunnckoCore]

choo does this IIRC

That's why I'm asking. I think it is immutable for reason. And that isn't only in choo, actually. "immutable" and "functional" are kinda trending these days.

I'm not so frontend, but I like that and I believe that's good and correct trend.

[jorgebucaran]

Can you freeze a number or an array or is it limited to objects?

What about simply not changing the model? The only reason you'd want to freeze the model is to avoid mutations, but you can also avoid this by not mutating the model yourself.

[tunnckoCore]

Can you freeze a number or an array or is it limited to objects?

No. In ES2015 it will return it, in below versions it will throw TypeError.

What about simply not changing the model?

For same reason that most devs use flow/typescript - guarantees, I kinda still don't like them, as I don't like the native assert and massive usage of it then "unassertifyfyfyfyfyf" (like Yosh and browserify & co devs does and promotes).

offtopic / 2c

edit: I'm strongly against that massive usage of assert and then unassertify "for production", because it drives you directly to the hell - unexpected errors, throws, awful stacktraces and etc.

edit2: Actually, that's the biggest reason that I don't like and don't use choo and won't use anything from that part of the community.

edit3: And that's the reason why I like hyperapp and that it is really 1-2kb with everything, not like choo which is "5kb", but browserify-ied (big bundles) and unassertify-ied (bad prod. experience)

[jorgebucaran]

Thanks for supporting Hyperapp, I like it too ;) but let's not derail this thread or any other to criticize choo. choo was a big source of inspiration for me.

With regards to the issue at hand, I have nothing against object.freeze, but I don't know if it is worth introducing in core.

[tunnckoCore]

but let's not derail this thread or any other to criticize choo. choo was a big source of inspiration for HyperApp.

Yea, it is great in anyway, I just sharing my view points. :)

[jorgebucaran]

@tunnckoCore Feel like we can close this?

[tunnckoCore]

yea, it is clear :)

[okwolf]

There's a mixin solution for this: https://github.com/okwolf/hyperapp-freeze

[tunnckoCore]

@okwolf that's cool idea, but any reasonable and logical reason to hardcode the deep-freeze package instead of including it as normally and expose cjs, es and umd bundles (with rollup for example, it's pretty easy)?

[jorgebucaran]

@charlike Yeah, I think he was in a hurry.

@okwolf This should be good to get you started.

• https://github.com/okwolf/hyperapp-logger/pull/1

Same cosmetic changes apply to hyperapp-freeze, etc. 👋

[okwolf]

@charlike yes @jbucaran is correct, hyperapp-freeze will get cleaned up after the hyperapp-logger refactor is complete.