You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Def thinking the way we're decoding these options into json arrays we should perhaps think about mapping these to real types... not sure what would be best as we could manually do it for the PHP side which would be sufficient but it's also from the go side right pushing them in.. opinions?
Yeah, agree about decoding into native types, as we can potentially validate the data even before it gets into the controller.
Validation is happening on the Go side thanks to Marshall and Unmarshall requirement of having to define these json structures as go types.
I also agree that we can use pure PHP for this, and gain a few neat features such as data types and expected values validation, a better structured codebase and thus cleaner code, and way less confusion on the controller side.
My suggestion is that we create the types and a class for serializing and deserializing these types from and to json. Then we replace the current option calls in the codebase with the native types ones which return known structures to PHP. Will be fun 😉
I see a good potential improvement here. Let's open a new issue based on this as the scope of doing it is probably gonna touch more parts of the codebase.
Def thinking the way we're decoding these options into json arrays we should perhaps think about mapping these to real types... not sure what would be best as we could manually do it for the PHP side which would be sufficient but it's also from the go side right pushing them in.. opinions?
Originally posted by @inverse in #34 (comment)
The text was updated successfully, but these errors were encountered: