Improve the ticking modal performance by removing the dependency on history loading

[brendanheywood]

In my experience the biggest bottle neck when loading the new ticking interface is blocking waiting on the previous ticking data for this route to be loaded to this api endpoint eg:

https://www.thecrag.com/api/node/id/1234567/mysummary?cookieAuth=1

1) I think this call could be completely eliminated, the page you are on already knows that you have ticked something before. I haven't tried to reverse engineer it but my guess is that the only reason is needs this call is to look up the previous quality rating you gave it before. A) This data could already be loaded in the main index page as part of the tick data for your previous ticks and re-use so you don't need the extra ajax call, and also B) It could be made completely redundant - I don't think it needs to be set as the default at all. I would regularly give a different ascent of the same route different ratings, I am rating that ascent not the route. If it was dirty or wet or whatever that affects my subjective experience on the day. If I tick it multiple times only my latest rating matters, and if I don't rate it then that's also fine. I think just like the tick type for each attempt this should be left with no default for each ascent.

It would be a pretty small change with a potentially large impact on the overall ticking experience.

A few other low hanging fruit which would also make a difference to the ticking ux:

2) I like to tick the routes in the order I climbed them, potentially repeating the same route in a session, so I tick them one at a time. The modal which pops up after each ticking showing the cpr to me adds no value and I ignore it and it slows me down. 3) When I tick I scroll up and down, find the route, the ticking modal pops up, and in the background the scroll state jumps around so when I am finished I'm not where I was. It appears to always scroll up about half a page.

[scd]

There is a fair bit of personal information we need when ticking, including the number of previous ascents, your quality assessment and your grade difficulty feedback. At this stage I am not prepared to spend significant work on multiple queries which may result in the overall server performance going down.

The other approach is to not make this query blocking for ticking and just disable related fields while it is loading. Then you only have to wait if you want to change your quality rating or difficulty feedback.

[brendanheywood]

The number of previous ascents is already loaded so is no extra load, it just needs to be passed into the modal:

The quality and grade I don't think should be loaded at all, they can default to empty and you can optionally re-rate it again if you want. I would definitely not make this blocking for just some related fields as it just moves the problem around. I've seen the api call take 30 seconds or more to load it would be better to just never make the call in the first place.

If I did actually want to make a new change to the quality or the grade then I would just do it as a fresh opinion having just climbed it again, my previous grade and rating is not important at all and I should not be prevented from using a field waiting for the old data to load just so I can change it to something new.

I think this is like rating a restaurant meal, you do it every single time even if you ordered the same dish from the same place. Some ascents of the same route are better than others and some are worse. Choss gets cleaned, crux holds fall off. If you have climbed the same route more than once with a large gap then I think it is better to not show the previous rating as it is a type of bias and maybe you've changed as a climber and have a different opinion now. If you don't give it a new rating each time that is just fine as your most recent one is still going to be the one that matters in all the stats.