Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 20 23:41
    Namek synchronize #207
  • Feb 20 23:37
    Namek synchronize #207
  • Feb 20 23:28
    Namek edited #207
  • Feb 20 23:25
    Namek synchronize #207
  • Feb 20 22:20
    Namek closed #206
  • Feb 20 22:19
    Namek closed #173
  • Feb 20 22:15
    Namek synchronize #207
  • Feb 20 22:15
    Namek synchronize #207
  • Feb 20 22:13
    Namek synchronize #207
  • Feb 20 21:50
    Namek synchronize #207
  • Feb 20 21:45
    Namek opened #207
  • Feb 20 19:00
    KevinSjoberg review_requested #202
  • Feb 20 18:58
    KevinSjoberg synchronize #202
  • Feb 20 15:40
    gdotdesign closed #167
  • Feb 20 15:30
    gdotdesign labeled #205
  • Feb 20 15:30
    gdotdesign labeled #205
  • Feb 20 15:30
    gdotdesign labeled #205
  • Feb 20 15:29
    gdotdesign closed #204
  • Feb 20 14:42
    Namek opened #206
  • Feb 20 14:40
    Namek opened #205
Szikszai Gusztáv
@gdotdesign
It's used in the compiler itself
Kevin Sjöberg
@KevinSjoberg
Yeah, just noticed. GitHub search failed me once again. I searched for normalizedEvent and it didn't return nothing but _normalizeEvent did.
Why are we normalising the event? I'm asking out of curiosity. I like to understand why things work the way they work. :slight_smile:
Kevin Sjöberg
@KevinSjoberg
Further, are the constants React and ReactDOM necessary within wrap_runtime itself, I would imagine the code necessary to render the root would be bundled within runtime.js?
Or with it not be able to run without them being present?
Szikszai Gusztáv
@gdotdesign
We are normalizing the event because properties can be different in different events MouseEvent, DragEvent, KeyboardEvent
Kevin Sjöberg
@KevinSjoberg
Ah, makes sense. :thumbsup:
Szikszai Gusztáv
@gdotdesign
they are exposed if we need them for example ReactDOM is used here: thttps://github.com/mint-lang/mint/tree/master/core/source
Kevin Sjöberg
@KevinSjoberg
Hmm, I see. Would there ever be a use case for them outside tests?
Szikszai Gusztáv
@gdotdesign
I don't know, maybe not
maybe if we want to allow third party React components
Kevin Sjöberg
@KevinSjoberg
Yeah, that could be a potential use case.
Oh, by the way. I had an idea this morning. :slight_smile:
Would it make sense to add a Mint version to the mint.json file? For instance, in Mint RealWorld it errors whenever you try to run mint install due to the fact that the structure of mint.json has changed between versions.
Right now you get a helpful message saying it didn't expect the key external-javascrips. A even more helpful message would be something like You're running Mint X but the project expects Mint Y.
Szikszai Gusztáv
@gdotdesign
we can :)
Kevin Sjöberg
@KevinSjoberg
Cool, I'd be happy to look into it. Any starting pointers?
Szikszai Gusztáv
@gdotdesign
the checking can be also here I think
Kevin Sjöberg
@KevinSjoberg
Alright, I'll give it a shot. I must say I've had so much fun since I've started playing around with Mint. You've truly created something really fun and useful. :slight_smile:
Szikszai Gusztáv
@gdotdesign
Thanks :smile: It's always great to hear :tada:
straw
@acoolstraw
This message was deleted
Kamil Dąbrowski
@Namek
oh hello
Kevin Sjöberg
@KevinSjoberg
👋 Hi!
Szikszai Gusztáv
@gdotdesign
hey :)
Kevin Sjöberg
@KevinSjoberg
How do the compiler specs get generated? By hand? If not, how are they generated? My branch caused a lot of the compiler specs to break and I want to update them accordingly but wasn't sure if that's an automated process (think snapshots) or manual one.
Szikszai Gusztáv
@gdotdesign
you mean the ones in spec/compilers?
they were generated by hand
Kevin Sjöberg
@KevinSjoberg
I see. Then I'll update those manually.
Szikszai Gusztáv
@gdotdesign
what changed?
Kevin Sjöberg
@KevinSjoberg
Szikszai Gusztáv
@gdotdesign
I think the API of the runtime should not change much or if it did the Compiler.wrap_runtime should handle those changes
then you don't have these kind of changes
Kevin Sjöberg
@KevinSjoberg
I don't think the API have any significant changes, most of the changes were related to _h being removed in favour of Preact.h. Since those variables are exposed to the end-user anyway and we already relied on having React and ReactDOM readily available I unified the API to a single location, Preact.
Basically giving you Preact.h, Preact.render, Preact.Fragment and Preact.createPortal.
Szikszai Gusztáv
@gdotdesign
Yeah I know. I've chosen _h the alias for createElement because it's shorter, using Preact.h would increase the size of the generated code.
there is no uglification step
Kevin Sjöberg
@KevinSjoberg
Oh, didn't know that.
Well, in that case, I can revert those changes ending up with const _h = mint.Preact.h.
Szikszai Gusztáv
@gdotdesign
yeah that was I was thinking
Kevin Sjöberg
@KevinSjoberg
I guess the same thing can be done for render, Fragment and createPortal.
Szikszai Gusztáv
@gdotdesign
sorry about not reviewing the PRs yet I'm working currently :(
Kevin Sjöberg
@KevinSjoberg
Any reason to why we underscore them? Are we thinking of anything within Preact as internal API?
If so, should everything be underscored?
No worries, being a contractor myself, I understand that work comes first. Whenever you have time. 🙂
Szikszai Gusztáv
@gdotdesign
to optimize things the compiler names variables / functions / etc with lowercase alphanumeric words so a, b, c might be taken by a local variable
this is where they are being generated https://github.com/mint-lang/mint/blob/master/src/js.cr#L394
Kevin Sjöberg
@KevinSjoberg
So do we want _createPortal, _h, _Fragment and _render then to stay consistent?
Szikszai Gusztáv
@gdotdesign
yes
Kevin Sjöberg
@KevinSjoberg
👍