cleanup: Use const values to handle layout / entries well known values and generate strings instead of hardcoding them #626
Conversation
3v1n0
force-pushed
the
common-consts
branch
2 times, most recently
from
c6d87de
to
be360ff
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #626 +/- ##
==========================================
+ Coverage 82.99% 83.11% +0.12%
==========================================
Files 80 81 +1
Lines 8584 8547 -37
Branches 75 75
==========================================
- Hits 7124 7104 -20
+ Misses 1129 1115 -14
+ Partials 331 328 -3 ☔ View full report in Codecov by Sentry. |
Yeah, I'm glad you think the same. I had it in the works for a while, maybe we should find a clean way to expose the shared ones with the brokers too, but for now even copying this is fine probably 😅 |
I was wondering if there is a reason why the broker doesn't depend on authd currently. To me it makes sense to share the constants between authd and the broker. @didrocks, WDYT? |
Yeah, ideally we should have an intermediate library that provides the shared elements that can be then used both by the example broker and any other go broker out there that we've now and that may show up in future |
…here We were duplicating this in the example broker, so let's make the same content be available everywhere.
Avoid (re)using string values for layout types as is, since they are prone to errors and they're hard to maintain.
Avoid (re)using string values for entries types as is, since they are prone to errors and they're hard to maintain.
Avoid building the list manually now that we've consts values and use this for both optional booleans and supported entries
It can be used to parse optional or required values or entries. Use this both in broker and example brokers logic
Avoid repeating the same string allover the places
We were using a maps of maps that made code hard to read and maintain and doing some unneeded conversions to json back and forth. Avoid this by just using structured data instead
So that we can reuse their ID across the file without further constants
Depending on the amount of elements we share. If those are only a few constants, maybe keeping up to date |
IIUC, these are constants which need to be in sync between authd and the broker, so the alternative is that we update them in both repos every time we change something there. I expect that to be more time consuming than only updating them in authd and then running |
A mono repo would make this even simpler of course 😁 |
Let’s go with this then! Just try to expose as public only the needed bits please! |
Want to handle it in a different PR or here? |
As you are adding the consts here, let’s expose them directly publicly |
|
Ok... Will move them. Ideally I would have used a different strategy though: we could have used proto files enums and expose them instead (after a rename) and use the same strategy to generate the JSON that is passed through dbus too (more or less how it happens with gdm), as it would have saved us lots of manual management of the types and the usage of But I'm unsure if that's too late now. |
We've various of hardcoded strings around that are often repeated and makes the code hard to maintain and refactor in a safely way.
So replace them with const values and add some utility functions to generate previously hardcoded values.
I've put them into the internal package, but I feel that some of these definitions would be actually better if exported to be re-usable by
authd-oidc-brokerstoo, or at least to an intermediate library for writing authd brokers.Meanwhile, this makes authd code a bit less fragile and ideally easier to refactor.
UDENG-5162