$screen helper

[SimoTod]

Let's chat about this.
$screen helper which returns true if the screen size is equal to or bigger than a given breakpoint.

Discussion point: Should we hardcode external frameworks settings inside the plugin, ask the user to specify the breakpoints somewhere, or just give a sensible default (documented) and allow the user to override it easily.

My personal view is that people tomorrow will question why X, Y, Z are supported but the new A framework is not, so I'm not a fan of giving those configurations here. On the other side, I'm not sure that asking people to define breakpoint by themselves would be a good idea so I'm a bit torn.

[MuzafferDede]

I would go with defining breakpoints by user instead of writing in the code. I am not sure what path would be the best to define these breakpoints only once and let $screen helper to initialize it.

Perhaps we could at least provide tailwindcss grid as default and a way to provide override?

@KevinBatdorf for your suggestion on callback, what would be the use case? Even there is one, can we just use $watch helper for that?

My add on to this helper would be providing touch detection, maybe portrait and landscape mode as well.

I used the have this idea of having a way to set Alpine related configurations to make almost anything configurable, but i think this would be a better approach for V3. (Not sure if there is still V3 roadmap tho)

[MuzafferDede]

Yeah, that will work i guess. Also we could use AlpineMagicHelpers as a global utility helper for any type of hooks.

[SimoTod]

I think it's safer if we don't use the Alpine namespace. The name could conflict in the future and we don't own the library

[KevinBatdorf]

AlpineMagicHelpers.Config.breakpoints sounds good to me.

[MuzafferDede]

I think we have a solid idea for the config part. @KevinBatdorf @SimoTod is it ok for you to do the AlpineMagicHelpers.Config with another PR then i re-factor $screen helper afterwards?

[KevinBatdorf]

I can make a PR. Not sure the best approach so I'll just implement what comes to mind first and we can discuss it.

[KevinBatdorf]

Another topic, should the debounce should be an option you can pass in? $screen('xl', {debounce: 0}) maybe? I don't necessarily like how it reads, but I can see it being useful.

[MuzafferDede]

My thoughts on debounce is $screen helper is a power hungry task because it updates element using $el.updateElements($el), which means everything on the component will be re-calculated. That's why i use debounce to prevent it. Giving users this as functionality might cause issues on large trees.

[SimoTod]

I think it's safer to just debounce for now as in the initial PR and add it later if we can find a use case where we want to configure it.

[KevinBatdorf]

I'm ok with that. Should we match Alpine's 250 default on inputs or is that too slow?

[MuzafferDede]

i think that might be a bit too slow, i use tailwindcss default duration which is 150.

[SimoTod]

I'm going to open a new discussion point for the second iteration of the $screen helper.
Should we support the screen orientation,$screen('portrait') and $screen('landscape')?
If yes, should it be the same helper or a new one? We need to consider that the breakpoint will need a listener on the resize event while an orientation change won't need that one but it will need to listen to a different event.
Also, should we implement it using height and width or just using window.matchMedia? The advantage of the latter is that the browser will work consistently with css for edge cases (for example when height and width are exactly the same).

[HugoDF]

$screen would be nice to have with both orientation, touch etc

if we decided to split them I guess we would do something like $breakpoint('lg') and $is('touch') or $detect('portrait')

The thing with portrait/landscape is that you can deal with it in CSS so dunno how much value it'll add to also be able to access them in JS

[MuzafferDede]

@SimoTod

Should we support the screen orientation,$screen('portrait') and $screen('landscape')?

@HugoDF

$screen would be nice to have with both orientation, touch etc

My initial thoughts was include anything related to screen to $screen helper. Didn't really want to increase the amount of the helpers to cause learning edge. jest and @KevinBatdorf's battle made me give up for now 😄

@HugoDF

The thing with portrait/landscape is that you can deal with it in CSS so dunno how much value it'll add to also be able to access them in JS

TBH, touch, and orientation support were add ons after initial thought. They are just why nots

@SimoTod

muzafferdede checked and he said that rotating your phone does not trigger a resize event (TBC) so components won't update.

@SimoTod i did check my comments if i said such a thing but i guess i didn't. Because i did check and actually even implemented a test as well for the orientationchange event which triggers resize event someway. So orientationchange = resize on mobile as well.

The things i couldn't do was tests on jest. Because there is no orientationchange support. I tried to mock and couldn't figure out. Sorry if i made any miss leading.

[SimoTod]

@MuzafferDede you did here -> #35 (comment)
After I asked if someone could check.

Not sure what game you are playing. :/

[SimoTod]

Anyway, topic closed, we don't need a listener on orientation change which is good.

[MuzafferDede]

@MuzafferDede you did here -> #35 (comment)
After I asked if someone could check.

Not sure what game you are playing. :/

Oh sorry, my bad, my bad. Stupid pass me! 😢 It's probably me just discovering things at that moment :) After that I actually tested it by console.log() in both event to see if I got 2 log messages. Which was so, then I did some more test and figure out mobile does trigger resize event. There was too much going on at that time. My bad.

BTW, I only play single game, DOTA 2 but I code more, which is more fun. You know 🙄