- 
          
 - 
                Notifications
    
You must be signed in to change notification settings  - Fork 8.6k
 
[rb] add mutable and immutable record objects to manage serialization #16518
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
base: trunk
Are you sure you want to change the base?
Conversation
          PR Compliance Guide 🔍Below is a summary of compliance checks for this PR: 
 Compliance status legend🟢 - Fully Compliant🟡 - Partial Compliant 🔴 - Not Compliant ⚪ - Requires Further Human Verification 🏷️ - Compliance label  | 
    ||||||||||||||||||||||||
| 
               | 
          ||
| def self.camel_to_snake(camel) | ||
| camel = camel.to_s | ||
| camel.gsub(/([A-Z\d]+)([A-Z][a-z])/, '\1_\2') | 
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data High
regular expression
library input
          PR Code Suggestions ✨Explore these optional code suggestions: 
  | 
    ||||||||||||
          CI Feedback 🧐A test triggered by this PR failed. Here is an AI-generated analysis of the failure: 
  | 
    
User description
I created a Struct subclass before that does not do what I thought it would do, so to start with, this is the fix for that.
The main idea is that instead of doing everything by Hash, we have 2 generic data structures, one for immutable objects (stuff that comes in as parameters from events), and one for mutable structures (stuff that gets edited). I think a lot of the things we're going to be working with in BiDi won't require much data processing of these types, but I figured it would be better to designate these than to just have everything as a Hash.
Ruby has a Data class for immutable arguments and a Struct class for mutable arguments.
Data.defineandStruct.newtake named parameters and create a subclass instance with those parameters as attr_reader or attr_accessor, with some other useful methods thrown in.These classes have 2 parts: the definition and the construction. Struct used
newfor both which was confusing, so wehn adding Data, they decided to usedefineas it is more obvious what you are doing.Baseline Ruby objects:
This PR adjusts those defaults slightly to better represent our use cases:
Definition phase is the same, except aliased to allow Struct.define for consistency in our code
Construction phase:
"camelStrings"to:snake_caseThis is essentially the pattern I figured out when working with ClientConfig PR, just normalized into the class itself.
Since I created this pattern for a ClientConfig class, it seemed like it made sense to have it in
Selenium::WebDriver::Typesinstead of somewhere inSelenium::WebDriver::BiDi.BiDi has a lot of sub-members for things, and this will allow us to do things like:
you can also add functionality during definition like:
I've marked these as
@api privatein case we want to do something different with them.PR Type
Enhancement
Description
Introduce
WebDriver::Types::DataandWebDriver::Types::Structclasses for managing serializationSupport camelCase to snake_case key conversion and optional keyword arguments
Replace
BiDi::Structwith new centralizedWebDriver::Types::StructimplementationRefactor
LogHandlerto use shared base log entry members with new Struct classDiagram Walkthrough
File Walkthrough
5 files
New Types module with normalization utilitiesImmutable Data class for event parametersRefactored Struct class with camelCase supportUpdate Window to use new Types::StructRefactor log entries with shared base members1 files
Remove old BiDi Struct autoload reference5 files
Update type signature for Window classUpdate type signatures for log entry classesAdd type signatures for Types moduleAdd type signature for Data classAdd type signature for Struct class1 files