Veritula – Meta
Showing only ideas leading to #2659 and its comments.
See full discussion·See most recent related ideasLog in or sign up to participate in this discussion.
With an account, you can revise, criticize, and comment on ideas.
Discussions are getting slower to render as they grow. It’s a rendering issue (not a db issue).
I could use ActionController::Live to stream top-level ideas to the page one by one. Instant page load.
Including that module significantly slows down hot reloads on all pages. I need a tight feedback loop in dev.
Replacing a raw SQL query in Idea.tree with a standard ActiveRecord query solves this issue.
Fast UX is more important than fast developer experience.
A slow developer experience will slow down all further development, including bug fixes and feature rollouts, which hurts UX as well.
After resetting my working directory and beginning to implement streams a second time, I can no longer reproduce this issue, despite reasonable attempts to reproduce it.
I’ve since been able to reproduce the issue after all. Running a raw SQL query in Idea.tree in combination with the inclusion of the Live module seems to mess with Rails’s reloader.
Incompatible with Devise authentication: https://github.com/heartcombo/devise/issues/2332
I could extract discussions#show into a new, separate StreamController or something like it. That controller would not use Devise.
The thread suggests a workaround: use authenticated do … blocks in routes.rb instead of before_action :authenticate_user! in controllers.
It’s probably a good idea to do this anyway to avoid divulging the existence of routes that unauthenticated users don’t need to know exist. (They will get a 404 instead of a 401.)
Then again, I’d want to redirect users to the sign-in page (and then ideally back to where they were trying to go).
I could override authenticate_user! in the DiscussionsController.
That means duplicate functionality; anytime I customize Devise in the future, I’ll have to remember to adjust this one method as well.
JS modules are always deferred and unusable until the page is fully loaded. As a result, comment buttons and gutters won’t work while ideas are still streaming onto the page.
I now purposely prevent interactions with buttons and gutters, and gray them out, until the page is fully loaded. So instead of broken hover effects and interactions, the user gets intentionally disabled elements, and this intentionality is communicated to them.
Once the page is fully loaded, buttons and gutters are enabled and visually restored.
Since the browser’s loading indicator remains visible until then, this behavior shouldn’t violate user expectation.
Now that parts of the page are purposely and visually disabled (see #2694), users may not expect everything to be working 100% during a loading state.
This problem will surface rarely – users would have to hit cmd + f immediately upon opening the page. For most users, by the time they start typing, the page is already fully loaded. So this seems like a small price to pay in exchange for discussion pages that always render faster.
This page used to take ~3.5 seconds to load. Now it renders within 600ms :)