For this week's and final contribution for Hacktoberfest 2024, I decided to contribute in the same project, onlook. As a Software Developer that is in the process of improving my skills in Web Development, I found this project interesting and also helpful to anyone in the field.
The open-source, local-first visual editor for your React Apps
Seamlessly integrate with any website or webapp running on React + TailwindCSS, and make live edits directly in the browser DOM. Customize your design, control your codebase, and push changes your changes without compromise.
Onlook.Studio.Component.Demo.for.GitHub.mp4
Built With
Stay up-to-date
Onlook officially launched our first version of Onlook on July 08, 2024 and we've shipped a ton since then. Watch releases of this repository to be notified of future updates, and you can follow along with us on LinkedIn or Substack where we write a weekly newsletter.
This time, I worked with a bugfix issue. The task requires implementing a validation logic to prevent users from inputting invalid values to some of the styling properties.
It is important to not allow users to input invalid values in styling such as negative values especially in styling properties where it doesn't make sense to have them. However, there are still styling properties where negative values have their own effect, to which this functionality should be kept available.
PR #4
For my pull request, is the solution I made to fix this bug. The repo owner has given me a tip that they already have implemented the necessary interfaces for the styles which contains the min and max attributes. They also already have the appropriate initialization of the classes of the styles, with the exception of enforcing the min/max attributes.
So the process is to figure out how the classes for the styles work, how I can enforce the min and max attributes, and where to put the validation logic.
It was easy to implement once I found where the classes are initialized since I just had to enforce the min and max values, which I will be able to use for the validation logic since these attributes are public attributes of the class.
Initially, I just added the validation logic directly in the handlers of the input. However, I noticed the amount of code repetition since I had to implement the validation to every handler for the different styles properties. So I tracked the main input component used by these styles properties and implemented the validation logic there instead. This prevents the code repetition for the validation. One of my concerns was that this solution wouldn't work if this input component is used somewhere else other than the styles properties, to which I made sure that it wasn't before implementing this solution.