Initial prompt to claude: okay... i want to embark on major plan for
architectural upgrate to this website. currently, when
loading a book, via url.com/book it pulls all the
nodes and highlights etc via @app/Http/Controllers/Dat
abaseToIndexedDBController.php then, on front page,
the data is loaded into the DOM via
@resources/js/lazyLoaderFactory.js therefore we have
lazyloading from indexedDB to dom... but that's it.
this makes load times long for really large books. we
pulling say 20 chunks of nodes when, initially at
least, we only need one. so the main purpose of
upgrade is to update both lazyloaderfactory and
databasetoindexedDBcontroller, to be able to initially
download only one chunk and then, add checks so, when
scroling triggers to pull chunk from indexedDB into
dom, if its not in indexedDb we try to pull from
server. but... that's a back up... what i really want
is, user is loading book, it pulls only one chunk,
then, as sooon as whole page is fully loaded and
working, we download the rest of the chunks to
indexedDB... so it shouldn't actually need to pull
each chunk as user scrolls... that is just a fail
safe.... as downloading a full book even a bible isn't
that big a deal.. we just trying to get inital load
times down. this is important for especially
hypercites... as then say im going to a specific part
of bible, via a hypercite, we only need to pull that
one chunk. so a hypercite to a part of bible should be
just as quick to one to a small letter, if that makes
sense? now.. here is where things get tricky. and
this is where we need to do a systemic review to make
sure that when we introduce this, we do not fully fuck
shit. 1. when loading a book, we need to know which
is the first chunk to pull... currently, user might
have saved scroll positions... right... so if we just
pull the first chunk, that might fuck with them
getting their scroll position restored. Alternatively,
if navigating to an internal id like a
url.com/book#hyperciteID ... we need to know what
chunk that hypercite is actaully in, and then serve
that chunk... so we'd have to get hypercite id, look
up in hypercite table, get nodeID look up in nodes
table, get chunk_id, send that as the intial chunk...
is this actually quicker than downloading all chunks?
potentially, for the purpose of htis upgrade, we might
need to do server caching of book data as json ready
to pull, including indexes of hypercites hyperlights
per chunk... not sure... now as to scroll position and
what chunk to pull.... this presents a further
challenge... this requires these backend process to
operate on a per-user level... so the url fetch
request needs to know what user is pulling hte book
data... then, we need to find scroll position saved
for that book for that user.... now, i do have a
proposal of how to get this right... but it is
experimental. and want your thoughts on whether it
will work. the idea is this: currenlty we save scroll
position to local storage, i believe from
@resources/js/scrolling.js or form
lazyloaderfactory.js... instead of this, i propose
taht we insert ab anchor tag at the top left visible
word on screen.... anchor tag like this the idea is that
as an inactive anchor tag, it shoudl not fuck with
dom layouts... and, as an id, it should enable user
scroll position to be returned not matter what device
user switches to, and as its in the text that was at
top of page, it should bring that up visibly on any
screen.... then, we need to have a table i guess,
where we store user bookmarks per book per user, with
chunk id... then, when fetching book and we have user
name and we DONt have a hypercite or hyperlight ot nav
to, we look up which first chunk to load from this
table... or whatever.... the other thing needing
investigation is, whether there are parts of hte
system that assume that all nodes are in indexedDB..
for example we might be doing an SPA nav and we have
library entry for a book so we assume we have all
chunks of nodes for that book in nodes object store in
IDB... but under this system we introduce a scenario
where we do not have them... so all of this needs to
be checked also.... fuck... pretty epic change... plz
let me know your thoughts..
Initial prompt to claude: okay... i want to embark on major plan for
architectural upgrate to this website. currently, when
loading a book, via url.com/book it pulls all the
nodes and highlights etc via @app/Http/Controllers/Dat
abaseToIndexedDBController.php then, on front page,
the data is loaded into the DOM via
@resources/js/lazyLoaderFactory.js therefore we have
lazyloading from indexedDB to dom... but that's it.
this makes load times long for really large books. we
pulling say 20 chunks of nodes when, initially at
least, we only need one. so the main purpose of
upgrade is to update both lazyloaderfactory and
databasetoindexedDBcontroller, to be able to initially
download only one chunk and then, add checks so, when
scroling triggers to pull chunk from indexedDB into
dom, if its not in indexedDb we try to pull from
server. but... that's a back up... what i really want
is, user is loading book, it pulls only one chunk,
then, as sooon as whole page is fully loaded and
working, we download the rest of the chunks to
indexedDB... so it shouldn't actually need to pull
each chunk as user scrolls... that is just a fail
safe.... as downloading a full book even a bible isn't
that big a deal.. we just trying to get inital load
times down. this is important for especially
hypercites... as then say im going to a specific part
of bible, via a hypercite, we only need to pull that
one chunk. so a hypercite to a part of bible should be
just as quick to one to a small letter, if that makes
sense? now.. here is where things get tricky. and
this is where we need to do a systemic review to make
sure that when we introduce this, we do not fully fuck
shit. 1. when loading a book, we need to know which
is the first chunk to pull... currently, user might
have saved scroll positions... right... so if we just
pull the first chunk, that might fuck with them
getting their scroll position restored. Alternatively,
if navigating to an internal id like a
url.com/book#hyperciteID ... we need to know what
chunk that hypercite is actaully in, and then serve
that chunk... so we'd have to get hypercite id, look
up in hypercite table, get nodeID look up in nodes
table, get chunk_id, send that as the intial chunk...
is this actually quicker than downloading all chunks?
potentially, for the purpose of htis upgrade, we might
need to do server caching of book data as json ready
to pull, including indexes of hypercites hyperlights
per chunk... not sure... now as to scroll position and
what chunk to pull.... this presents a further
challenge... this requires these backend process to
operate on a per-user level... so the url fetch
request needs to know what user is pulling hte book
data... then, we need to find scroll position saved
for that book for that user.... now, i do have a
proposal of how to get this right... but it is
experimental. and want your thoughts on whether it
will work. the idea is this: currenlty we save scroll
position to local storage, i believe from
@resources/js/scrolling.js or form
lazyloaderfactory.js... instead of this, i propose
taht we insert ab anchor tag at the top left visible
word on screen.... anchor tag like this the idea is that
as an inactive anchor tag, it shoudl not fuck with
dom layouts... and, as an id, it should enable user
scroll position to be returned not matter what device
user switches to, and as its in the text that was at
top of page, it should bring that up visibly on any
screen.... then, we need to have a table i guess,
where we store user bookmarks per book per user, with
chunk id... then, when fetching book and we have user
name and we DONt have a hypercite or hyperlight ot nav
to, we look up which first chunk to load from this
table... or whatever.... the other thing needing
investigation is, whether there are parts of hte
system that assume that all nodes are in indexedDB..
for example we might be doing an SPA nav and we have
library entry for a book so we assume we have all
chunks of nodes for that book in nodes object store in
IDB... but under this system we introduce a scenario
where we do not have them... so all of this needs to
be checked also.... fuck... pretty epic change... plz
let me know your thoughts..