-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PM-11764] Implement account switching and sdk initialization #1116
[PM-11764] Implement account switching and sdk initialization #1116
Conversation
New Issues
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1116 +/- ##
==========================================
- Coverage 58.34% 58.18% -0.17%
==========================================
Files 193 197 +4
Lines 13541 13584 +43
==========================================
+ Hits 7901 7904 +3
- Misses 5640 5680 +40 ☔ View full report in Codecov by Sentry. |
remaining: UUID
08e889d
to
e23e30b
Compare
I really shouldn't need to be fixing this
919c591
to
0105672
Compare
#[cfg(feature = "wasm")] | ||
#[wasm_bindgen::prelude::wasm_bindgen(typescript_custom_section)] | ||
const TS_CUSTOM_TYPES: &'static str = r#" | ||
export type AsymmetricEncString = string; | ||
"#; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a uniffi_support.rs
file, would it make sense to add something similar for these custom logics? Or should we encourage lifting in the uniffi logic to where it's needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added custom_types.rs
which is inspired by that uniffi file, but I think adding the types where they are defined is a preferred approach. It's just that we sometimes use external type and so I needed both approaches
This change removes any direct dependency on error enums and instead relies on the `ToString` trait to convert any and all errors to strings. A follow-up ticket will have to investigate how we best implement support for catching specific errors
…-initialization
Adding @dani-garcia as reviewer because @Hinton is traveling/at conference |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -6,6 +6,8 @@ use bitwarden_crypto::{ | |||
}; | |||
use schemars::JsonSchema; | |||
use serde::{Deserialize, Serialize}; | |||
#[cfg(feature = "wasm")] | |||
use {tsify_next::Tsify, wasm_bindgen::prelude::*}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I just discovered now thanks to this that you can use a top level {}
block in a use
statement, neat!
@@ -27,7 +29,7 @@ fn convert_level(level: LogLevel) -> Level { | |||
// Rc<...> is to avoid needing to take ownership of the Client during our async run_command | |||
// function https://github.com/rustwasm/wasm-bindgen/issues/2195#issuecomment-799588401 | |||
#[wasm_bindgen] | |||
pub struct BitwardenClient(Rc<Client>); | |||
pub struct BitwardenClient(pub(crate) Rc<Client>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub struct BitwardenClient(pub(crate) Rc<Client>); | |
pub struct BitwardenClient(Rc<Client>); |
Nit: This inner value is only used on it's own impl as far as I know, so we don't need it to be pub(crate)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎟️ Tracking
📔 Objective
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes