+ Cache is no longer contained in app structure
This should let us later throw this into an Arc<Mutex<>> for better
async support.
! Also more cache access safety is being done on the front end because the cahe doesn't guarantee much on access
Perhaps some convenience wrappers would make this look nicer(with inline)
!!! Main needs a lot of flattening
It's technically not much of a problem since most of the code behind 1/2 match's
which really just bloat the hell out of indentation making it look bad when its not _that_ bad.
However it still bugs me so I should probably do something about that(also (inline))
From this point forward the cache should basically just be a data container.
Methods on the cache object are there for convenience and should only ever
return very simple data [booleans, integers, () etc.].
The cache should also have very litter/no concept of commands to decouple it
from the renderer process.
! list_channels is still implemented in the cache however it remaains a vestige
and will be moved to the net module
Also the client is getting some new packages for websocket connections and
while they work some additional work has to be put in to figure out where fug to
actually place the websocket so that it can update the cache+DOM in a seomewhat sensible fashion
Of course this is an issue because we can no longer get data from the user
A full rearchitecting may be in order here however its not impossible to modify the current architecture so far
The main issue here is that the cache is doing too much I think
If the termion(main input) task does its thing, and a socket task,
waits around waiting to build a sub task(socket) then we may be able to
pass messages to the socket task to open up sockets when request
This allows us to have shared state via message passing and a main task
can take care of updating the cache.
The renderer can then request data from the cache when it needs to render stuff
Issue was that we weren't sending the correct headers/body data(ya I know)
- Removing mouse control from app since its completel irrelevant
!+ Putting app messagses behind a mutex for now since they are written to by
sockets and renderer process in the next few patches
More agressive channel caching may be required here but it works as an MVP for now
* Switch to hashmap for container of channel caches instead of vector
This should help with cache accesses as we don't have to iterate anymore
Also it makes data fetches much cleaner/shorthanded
* net::list_channels has its own private structure for collecting channels vector
This is basically required and is in the scope of the func itsefl to not pollute any other namespaces
! No wrapper goes around this module to avoid fragmentation
Note that basically every network hit is built around try's so they'll all return
HttpResult<T>'s
Technically everything is there but I haven't really tested anything yet
Will 100% need fixing + optimizing
+ Switch server Command also working
! Requires a jwt check to avoid expensive+unnecssary network /login hits
! Probably have to hold onto the input to avoid spam somehow
ChannelCache is nearly ready for manipulation
+ Option to enable/disable message-box borders
* Switching over to using bold! macro where applicable (especially in command.rs)
This change mostly reduces the eyesoreness of the termion code
+ Option to enable/disable message-box borders
* Switching over to using bold! macro where applicable
This change mostly reduces the eyesoreness of the termion code
* Also changed up the naming scheme to be more clear
* Config -> ConfigFile
- Removed ConfigFile::server_url method
! The ConfigFile struct is now pretty much entirely used for disk operations
* update_jwt method also take in correct parameters
This patch is simply meant to mark the beginning of the newest phase for the tui build.
I've 100% settled on using termion as the backend and marking what is done so far
Renderer side:
Termion has a similar issue where moving data happens very quietly so its best
if the two (renderer and cache) have the their data to use as they please
Cache Side:
Basically we own the data we're using because we constantly have to mutate data
ourselves
Config in the middle:
Mutable but only from the rendering side because the cache is completely transient
It technically to own its data but it does anyway because the render(backend)
likes to consume data like there's no tomorrow
