[PM-33496] Loosen parsing rules by introducing a new Expected value type#127
Conversation
|
Thank you for your contribution! We've added this to our internal tracking system for review. Details on our contribution process can be found here: https://contributing.bitwarden.com/contributing/pull-requests/community-pr-process. |
Expected value typeExpected value type
|
I pushed two more commits which add a bunch of nice utilities to make upgrading to this new version easier. I ran out of time yesterday, so I spent today integrating these new patches into our codebase. Let me know what you think! |
|
Since this PR went through a few versions, I am going to clean up the history a bit once you're happy with the code. |
It will all be squashed in the end so no strict need to do that. |
|
I ran out of time reviewing this today. Overall I like the concept but it's a bit verbose and slightly clunky due to handling of valid but wrong field type. I'm experimenting with passing in the editable field type in the |
Progdrasil
left a comment
There was a problem hiding this comment.
Just a small nit, otherwise LGTM
There was a problem hiding this comment.
Apologies for the slow review cycle. Overall I quite like this approach, thank you for continuing to iterate on it. I think we're duplicating things and I've suggested some improvements which I think will reduce the duplicated logic. Let me know what you think!
|
@Hinton sorry for the long turnaround time -- I think I managed to address most of your comments. I will rebase once you're happy with the current impl |
There was a problem hiding this comment.
Apologies for the delay.
This looks good, we should rebase it and I think we can merge it. It's somewhat annoying that we have two deserialize one for EditableFieldValue and one for EditableField but there doesn't seem to be any good way of eliminating it.
This helps us with parsing non-compliant CXF (for instance when someone passes in `string` instead of `concealed-string`) while also retaining type safety and compliant exports.
421aa4c to
5b4b6d5
Compare
|
@Hinton I think all your comments are now addressed :) |
Hinton
left a comment
There was a problem hiding this comment.
I'll do quick smoke test of this in our implementation tomorrow but should be good to go.
Thanks for working on this!
Good idea, I'm taking this for a spin as well on our side
Thanks for bearing with me -- I'm grateful for all the reviews you left on my patches! |
|
@Hinton I found one thing that made my life a lot easier: a conversion from editable field to string. It looks like it's working as expected on my side :) |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #127 +/- ##
==========================================
- Coverage 66.02% 62.04% -3.98%
==========================================
Files 5 5
Lines 518 685 +167
==========================================
+ Hits 342 425 +83
- Misses 176 260 +84 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🎟️ Tracking
Solves #122
📔 Objective
Follow-up from our discussion on #126. Let me know what you think!
⏰ Reminders before review
🦮 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 confirmed issue 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