title: Slow load time using React and Quill.js
body: <p>I’m currently working on a project built in React on the front-end and a node framework called Sails.js that’s integrated with PostgreSQL on the back end. The core functionality of the site allows users to read, edit and search for verses from the Bible, Book of Mormon and other volumes of scriptures.</p>
  
  <p>The data flow is the standard: user hits an endpoint -> postgres query returns data -> verses are returned to our front-end. The way it currently works on the front-end is that each verse is a JSX component that gets wrapped in a Quill.js component which allows users to mark it up and add their own notes to words or phrases. The problem is, when a user searches for a term than returns more than even 20-30 verses, everything goes VERY slow. If we comment out the Quill component, it’s nearly instant. But when there are queries returning 50+ verses with Quill wrappers, it is unbearably slow to load all that to the browser (1 minute plus load time).</p>
  
  <p>So clearly, we need a way to speed that terrible UX up. The solutions we have considered so far include:</p>
  
  <ul>
  <li>Rendering only 1 wrapper Quill component for all verses. This is fast
  but doesn’t work because then users can markup more than one verse at
  a time, which can’t be saved to our database, which is divided into
  verses. If a search returns a query set with various unrelated
  verses, users will end up marking up verses which we couldn’t track.</li>
  <li>Lazy loading verses. Problem being users will often / always
  eventually want all of them loaded, so this seems to just stretch out
  the load time instead of waiting on the front end of the operation.
  Conditionally rendering an editable verse vs. and un-editable verse.
  There could be a toggle per user or per verse that would either allow
  or disallow editing and re-render the verse components accordingly.
  Downside being that it’s annoying and slightly clunky.</li>
  <li>Conditionally rendering an editable verse in response to an event
  listener on a verse component. The problem seems like it would be
  that a user would not know that verses are only conditionally
  editable, so they would go to edit one and receive a frustrating
  re-render while they are highlighting a verse.</li>
  <li>None of these ideas seem great to me, and I feel like we may just be
  limited by the requirements of the architecture. Am I missing
  something obvious? Is there a way to do this that would allow users
  to fluidly edit any verse they want on demand that won’t also slow
  down the browser unbearably, even in cases of very large loads?</li>
  </ul>
  
  <p>Thanks for reading and any potential help!</p>