Re: about current framework release (was Re: Routing (was Re: Spectrum Components))

[Carlos Rovira]

Hi Alex,

I'm just exposing that in the other repos there was various tries and
reverts. I was expecting the same here. If you are getting enough progress
to get the release in few hours, that's great. But maybe exposing you got
all working to finish the release and send an email to the list will be
just fine as a courtesy for the rest of the team (not just me).

The fact is that I fixed some things in Jewel scrollToIndex last night and
then you got to step 9, but seems there was a build problem catched by
Yishay with an import left in Jewel. So that will make the release fail for
sure.

A part from that, not me, but others could need to add things...or I could
be wrong. I must say I don't need to add anything myself. So from my
perspective you can go and finish as you prefer. Just thinking on others,
not me :)







El vie., 17 abr. 2020 a las 18:46, Alex Harui ()
escribió:

> Hi Carlos,
>
> First you are complaining that I was not making enough progress on the
> release.  Then there have clearly been Release_Step emails this week and
> you are now claiming I did not give you enough warning?
>
> -Alex
>
> On 4/17/20, 9:38 AM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> a part from the issue with version bumped, I thought that you were
> testing
> and changing, and this could be just a test as done in compiler.
> If this is the real release, great. But in that case, I think you
> should
> cherry pick my latest commit removing a class (scrollToIndex) since
> right
> now Jewel is broken. I think others could need to add something to
> enter
> the release as we did other times, if so maybe just asking to people if
> want for a last call to add something would be good.
>
> Thanks
>
> El vie., 17 abr. 2020 a las 17:54, Alex Harui
> ()
> escribió:
>
> > Ideally, supporting the route information in parameters vs hash
> would be
> > done in a PAYG way.
> >
> > AIUI, hash has to be used as the delimiter if you plan to change the
> route
> > information within the application, otherwise the application will
> reload.
> > IOW, if the user is going to navigate in the appiication and the
> route
> > information is going to change as they navigate, hash should be
> used.  If,
> > on the other hand, there are a bunch of links on a website to click
> and you
> > end up on a "page", then URL parameters is probably ok.
> >
> > I don't understand the concern about the dev branch version.  The
> release
> > branch for 0.9.7 has been cut.  Any changes that go in develop are
> going in
> > the next release.  That's how the git branching model works.  You
> can make
> > any change you want in the dev branch right now.  It just won't be
> in the
> > 0.9.7 release unless the RM decides to cherry-pick it, which they
> should
> > not unless it is really important.  What am I missing?
> >
> > -Alex
> >
> > On 4/17/20, 3:09 AM, "Harbs"  wrote:
> >
> > Whatever you think is fine by me.
> >
> > I don’t remember why I have "if(location.hash)”. It’s possible
> you can
> > get rid of that conditional.
> >
> > It could be you can get rid of that and handle hashRecieved in a
> bead.
> > If the hashReceived event has no hash you can then check the URL.You
> do
> > need to make sure that you always get a stateChange event and don’t
> > dispatch it twice.
> >
> > Feel free to play around with the code… ;-)
> >
> > Harbs
> >
> > > On Apr 17, 2020, at 11:37 AM, Piotr Zarzycki <
> > piotrzarzyck...@gmail.com> wrote:
> > >
> > > I think it would be better to have it here in Router.
> > >
> > > pt., 17 kwi 2020 o 09:37 Harbs 
> napisał(a):
> > >
> > >> Alternatively, you can subclass Router to support setting the
> > parameters
> > >> in the onInit method.
> > >>
> > >> Not sure which of these is best.
> > >>
> > >>> On Apr 17, 2020, at 10:35 AM, Harbs 
> wrote:
> > >>>
> > >>> Actually, it’s not going to work because the
> > >> router.routeState.parameters will not be set.
> > >>>
> > >>> You will likely need to add code to set the
> > router.routeState.parameters
> > >> using the part of the location after the question mark.
> > >>>
> > >>> The easiest way to do that would be to either:
> > >>> 1. Modify RouteToParameters.stateChanged to first check that
> there
> > is a
> > >> parameters value and then set it if not.
> > >>> 2. Subclass RouteToParameters and override stateChanged to
> make
> > that
> > >> check first.
> > >>>
> >  On Apr 17, 2020, at 10:29 AM, Harbs  >  > >> harbs.li...@gmail.com>> wrote:
> > 
> >  I’m pretty sure it’ll work without the hash as well.
> > 

Re: about current framework release (was Re: Routing (was Re: Spectrum Components))

[Alex Harui]

Hi Carlos,

First you are complaining that I was not making enough progress on the release. 
 Then there have clearly been Release_Step emails this week and you are now 
claiming I did not give you enough warning?

-Alex

On 4/17/20, 9:38 AM, "Carlos Rovira"  wrote:

Hi Alex,

a part from the issue with version bumped, I thought that you were testing
and changing, and this could be just a test as done in compiler.
If this is the real release, great. But in that case, I think you should
cherry pick my latest commit removing a class (scrollToIndex) since right
now Jewel is broken. I think others could need to add something to enter
the release as we did other times, if so maybe just asking to people if
want for a last call to add something would be good.

Thanks

El vie., 17 abr. 2020 a las 17:54, Alex Harui ()
escribió:

> Ideally, supporting the route information in parameters vs hash would be
> done in a PAYG way.
>
> AIUI, hash has to be used as the delimiter if you plan to change the route
> information within the application, otherwise the application will reload.
> IOW, if the user is going to navigate in the appiication and the route
> information is going to change as they navigate, hash should be used.  If,
> on the other hand, there are a bunch of links on a website to click and 
you
> end up on a "page", then URL parameters is probably ok.
>
> I don't understand the concern about the dev branch version.  The release
> branch for 0.9.7 has been cut.  Any changes that go in develop are going 
in
> the next release.  That's how the git branching model works.  You can make
> any change you want in the dev branch right now.  It just won't be in the
> 0.9.7 release unless the RM decides to cherry-pick it, which they should
> not unless it is really important.  What am I missing?
>
> -Alex
>
> On 4/17/20, 3:09 AM, "Harbs"  wrote:
>
> Whatever you think is fine by me.
>
> I don’t remember why I have "if(location.hash)”. It’s possible you can
> get rid of that conditional.
>
> It could be you can get rid of that and handle hashRecieved in a bead.
> If the hashReceived event has no hash you can then check the URL.You do
> need to make sure that you always get a stateChange event and don’t
> dispatch it twice.
>
> Feel free to play around with the code… ;-)
>
> Harbs
>
> > On Apr 17, 2020, at 11:37 AM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com> wrote:
> >
> > I think it would be better to have it here in Router.
> >
> > pt., 17 kwi 2020 o 09:37 Harbs  napisał(a):
> >
> >> Alternatively, you can subclass Router to support setting the
> parameters
> >> in the onInit method.
> >>
> >> Not sure which of these is best.
> >>
> >>> On Apr 17, 2020, at 10:35 AM, Harbs  wrote:
> >>>
> >>> Actually, it’s not going to work because the
> >> router.routeState.parameters will not be set.
> >>>
> >>> You will likely need to add code to set the
> router.routeState.parameters
> >> using the part of the location after the question mark.
> >>>
> >>> The easiest way to do that would be to either:
> >>> 1. Modify RouteToParameters.stateChanged to first check that there
> is a
> >> parameters value and then set it if not.
> >>> 2. Subclass RouteToParameters and override stateChanged to make
> that
> >> check first.
> >>>
>  On Apr 17, 2020, at 10:29 AM, Harbs   >> harbs.li...@gmail.com>> wrote:
> 
>  I’m pretty sure it’ll work without the hash as well.
> 
>  Give it a try.
> 
> > On Apr 17, 2020, at 10:23 AM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com >
> wrote:
> >
> > Hi Harbs,
> >
> > Thanks for pointing me out, but this is still that Routing
> expects me
> >> to
> > use in url hashes - The question is - What if I can't use
> hashes, but
> >> url
> > looks like I have presented in previous email ?
> >
> > Thanks,
> > Piotr
> >
> > pt., 17 kwi 2020 o 09:20 Harbs  >> harbs.li...@gmail.com>> napisał(a):
> >
> >> This app uses both path based and query based routing:
> >>
> >>
> 

about current framework release (was Re: Routing (was Re: Spectrum Components))

[Carlos Rovira]

Hi Alex,

a part from the issue with version bumped, I thought that you were testing
and changing, and this could be just a test as done in compiler.
If this is the real release, great. But in that case, I think you should
cherry pick my latest commit removing a class (scrollToIndex) since right
now Jewel is broken. I think others could need to add something to enter
the release as we did other times, if so maybe just asking to people if
want for a last call to add something would be good.

Thanks

El vie., 17 abr. 2020 a las 17:54, Alex Harui ()
escribió:

> Ideally, supporting the route information in parameters vs hash would be
> done in a PAYG way.
>
> AIUI, hash has to be used as the delimiter if you plan to change the route
> information within the application, otherwise the application will reload.
> IOW, if the user is going to navigate in the appiication and the route
> information is going to change as they navigate, hash should be used.  If,
> on the other hand, there are a bunch of links on a website to click and you
> end up on a "page", then URL parameters is probably ok.
>
> I don't understand the concern about the dev branch version.  The release
> branch for 0.9.7 has been cut.  Any changes that go in develop are going in
> the next release.  That's how the git branching model works.  You can make
> any change you want in the dev branch right now.  It just won't be in the
> 0.9.7 release unless the RM decides to cherry-pick it, which they should
> not unless it is really important.  What am I missing?
>
> -Alex
>
> On 4/17/20, 3:09 AM, "Harbs"  wrote:
>
> Whatever you think is fine by me.
>
> I don’t remember why I have "if(location.hash)”. It’s possible you can
> get rid of that conditional.
>
> It could be you can get rid of that and handle hashRecieved in a bead.
> If the hashReceived event has no hash you can then check the URL.You do
> need to make sure that you always get a stateChange event and don’t
> dispatch it twice.
>
> Feel free to play around with the code… ;-)
>
> Harbs
>
> > On Apr 17, 2020, at 11:37 AM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com> wrote:
> >
> > I think it would be better to have it here in Router.
> >
> > pt., 17 kwi 2020 o 09:37 Harbs  napisał(a):
> >
> >> Alternatively, you can subclass Router to support setting the
> parameters
> >> in the onInit method.
> >>
> >> Not sure which of these is best.
> >>
> >>> On Apr 17, 2020, at 10:35 AM, Harbs  wrote:
> >>>
> >>> Actually, it’s not going to work because the
> >> router.routeState.parameters will not be set.
> >>>
> >>> You will likely need to add code to set the
> router.routeState.parameters
> >> using the part of the location after the question mark.
> >>>
> >>> The easiest way to do that would be to either:
> >>> 1. Modify RouteToParameters.stateChanged to first check that there
> is a
> >> parameters value and then set it if not.
> >>> 2. Subclass RouteToParameters and override stateChanged to make
> that
> >> check first.
> >>>
>  On Apr 17, 2020, at 10:29 AM, Harbs   >> harbs.li...@gmail.com>> wrote:
> 
>  I’m pretty sure it’ll work without the hash as well.
> 
>  Give it a try.
> 
> > On Apr 17, 2020, at 10:23 AM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com >
> wrote:
> >
> > Hi Harbs,
> >
> > Thanks for pointing me out, but this is still that Routing
> expects me
> >> to
> > use in url hashes - The question is - What if I can't use
> hashes, but
> >> url
> > looks like I have presented in previous email ?
> >
> > Thanks,
> > Piotr
> >
> > pt., 17 kwi 2020 o 09:20 Harbs  >> harbs.li...@gmail.com>> napisał(a):
> >
> >> This app uses both path based and query based routing:
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Funhurdle.github.io%2Fspectrum-royale%2F%23!asset%3Fcolorstop%3Ddarkdata=02%7C01%7Caharui%40adobe.com%7C3f371b8193974ec8a47d08d7e2b77733%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637227149925562717sdata=kGEULHJDYvZ1XHxq1GRF0FNx5%2BBwoXjDTZHw%2BppF6ks%3Dreserved=0
> <
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Funhurdle.github.io%2Fspectrum-royale%2F%23!asset%3Fcolorstop%3Ddarkdata=02%7C01%7Caharui%40adobe.com%7C3f371b8193974ec8a47d08d7e2b77733%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637227149925562717sdata=kGEULHJDYvZ1XHxq1GRF0FNx5%2BBwoXjDTZHw%2BppF6ks%3Dreserved=0>
> <
> >>
>