Conversation
Parth
left a comment
There was a problem hiding this comment.
- I think a mild readme in pub site would go a long way describing the overall build, tools used, etc.
- I would prefer to move the public_site into the docs folder.
- how much effort would light mode / dark mode take? can happen after merge.
- we should think about what deployment will take, can happen after merge.
Cargo.toml
Outdated
| "utils/dev-tool", | ||
| "utils/releaser", | ||
| "utils/winstaller", | ||
| "public-site/trunk", |
There was a problem hiding this comment.
Does it make sense to call this component trunk?
There was a problem hiding this comment.
yeah it does make sense for me
libs/content/workspace/src/show.rs
Outdated
| } | ||
| } | ||
| TabContent::Image(img) => img.show(ui), | ||
| #[cfg(not(target_family = "wasm"))] |
There was a problem hiding this comment.
if you do this slightly differently you may deliver #2701
libs/content/workspace/Cargo.toml
Outdated
| tracing-test = "0.2.5" | ||
| indexmap = { version = "2.5.0", features = ["rayon"] } | ||
| futures = "0.3.30" | ||
| web-time = "=1.1.0" |
| ) -> Result<Vec<u8>, reqwest::Error> { | ||
| let response = client.get(url).send()?.bytes()?.to_vec(); | ||
| Ok(response) | ||
| fn download_image(client: &reqwest::Client, url: &str) -> Result<Vec<u8>, reqwest::Error> { |
There was a problem hiding this comment.
resolve once someone has checked to make sure this still works fine for the editor.
I recall images being vaguely broken in someway, if it's because of our inability to get them can we just include_bytes! them?
If it's something else maybe graphics related wanna just leave some context.
There was a problem hiding this comment.
I also see that reqwests has some wasm things going on if it is a networking issue
There was a problem hiding this comment.
yeah it broke the editor. but i fixed it and also fixed it on wasm so we can include images in the demo
libs/lb/lb-rs/Cargo.toml
Outdated
| strip-ansi-escapes = "0.2.0" | ||
| chrono = "0.4" | ||
| rand = "0.8.4" | ||
| getrandom = { version = "0.2", features = ["js"] } |
There was a problem hiding this comment.
does this remove rand? rand does support wasm iirc. Rand has cryptography implications iirc. Will continue to review.
There was a problem hiding this comment.
same for git-lfs for these assets, maybe all pngs in this folder. Or you can pursue more aggressive compression. The overall repo should be fast to clone. There's some historic cleanup we have to do anyways. Cloning the repo is something a lot of scripts / CI / installers do.
.gitattributes
Outdated
| *.jpg filter=lfs diff=lfs merge=lfs -text | ||
| *.png filter=lfs diff=lfs merge=lfs -text | ||
| *.jpeg filter=lfs diff=lfs merge=lfs -text |
There was a problem hiding this comment.
I think these are ideally constrained to the public_site directory I don't want to break workspace logo or something like that
server/Cargo.toml
Outdated
| jsonwebtoken = "8.2.0" | ||
| x509-parser = { version = "0.15.0", features = ["verify", "validate"]} | ||
| db-rs = "0.3.1" | ||
| db-rs = {git="https://github.com/lockbook/db-rs"} |
There was a problem hiding this comment.
0.3.2 was published you can probably refer to this normally now
|
@ad-tra can you go through and resolve what you feel like you've completed? I checked a few things and found mixed results |
|
@tvanderstad can you do a pass over the editor bits? |
tvanderstad
left a comment
There was a problem hiding this comment.
Overall, this feels like it creates a small mess in order to deliver the feature quickly. I'm on board if we can align on a target state and a timeline to achieve it, and I'm down to do my part.
Here's a pitch to get us started:
- Let's aim to drop WASM support for
lb-rsand workspace, where the undue portion of the mess is concentrated imo, and instead ship just the editor and canvas modules (with simple wrappers if necessary). - I can start by factoring dependencies on
lb-rsandworkspaceout of the editor. I'll just have it accept an optionalFilePathResolverof some kind so we can resolve relative links in our apps and not depend onlb-rsin WASM (a feature I want to add anyway). I'll move any workspace helper functions to wherever I need to to make it happen. I'll aim to finish by the end of this quarter (2025 Q2). - You can apply the same pattern to canvas like we did with collaborative editing, then revert the
lb-rsandworkspacechanges that were needed to support those in WASM, aiming to finish by end of Q3.
These timelines are approximate. Basically I see some of the changes as tech debt - the conditional compilation forces me to basically maintain two programs simultaneously which has been a bad time in the past - but we only pay interest on that tech debt when we're maintaining or building on that code. For example, if we want to up our persistence game and persist scroll positions in open files, we'll be reminded that PDFs are only present in the workspace content types enum for some targets. So here I'm saying Q2 or Q3 as a guess for "when is the next significant change to something affected by the debt" or possibly "when is the next engineer to onboard to the code affected by the debt".
libs/lb/lb-rs/Cargo.toml
Outdated
| bincode = "1.3.3" | ||
| time = "0.3.20" | ||
| diffy = "0.3.0" | ||
| db-rs = {git="https://github.com/lockbook/db-rs"} |
There was a problem hiding this comment.
is this intended to stay this way? also, nit: formatting
There was a problem hiding this comment.
not intended, the change has been released
libs/lb/lb-rs/src/blocking.rs
Outdated
| where | ||
| F: Future, | ||
| { | ||
| block_on(future) |
There was a problem hiding this comment.
nit: I prefer to qualify instead of import a raw fn like this. There are a lot of block_on's happening around here
| block_on(future) | |
| futures::executor::block_on(future) |
libs/lb/lb-rs/src/io/mod.rs
Outdated
| let start = Instant::now(); | ||
|
|
||
| // let guard = tokio::time::timeout(std::time::Duration::from_secs(1), self.db.read()) | ||
| // let guard = web_timetimeout(std::time::Duration::from_secs(1), self.db.read()) |
There was a problem hiding this comment.
nit: probably-unintended comment change
| #[cfg(not(target_arch = "wasm32"))] | ||
| thread::spawn(move || { |
There was a problem hiding this comment.
Could we have used something from futures, the way you managed the blocking behavior in lb-rs, to make the functions in this file async whether they're wasm or not? Then we wouldn't need two versions and I imagine this diff would be much cleaner (if yes I can make the change later)
|
Alternatively -- we could explicitly support wasm. I think there are situations where a web app makes sense and it would be annoying to factor all those things out of the editor and canvas for effectively no reason long term. I think this forces us to do things the wasm way for the wasm situation, but my ideal investment would be to understand if these are just fundamentally the right ways to do these things anyways? Is it more correct for something like lb-rs (which has no main method) to just depend on a general But broadly I'm aligned on mess reduction happening in this quarter if this is merged. I think this would still be a reasonable state for the standalone editor, lb-rs would go to resolve a link and find that you're not logged in and would not resolve the link if it's lb://. |
|
And I'm down to make the lb-rs support of wasm my problem. |
|
we chatted after standup and basically I think both things are going to happen
but either way you should rebase and merge this |
|
@tvanderstad I'm assuming you're certifying the editor changes |
|
@ad-tra I would ideally merge this after wed's release |
|
nix-release depends on |
No description provided.