Refactor form-helper functions into more streamlined API #106
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Simplifying the function APIs
I've refactored the
form-helper
functions into a simpler — in my opinion — API to avoid passing what I thought was a needless dictionary and key to the functions. I think this refactor removes some redundancy from the API.Currently
Most of the time, I want to create a text input form with the
name
andplaceholder
attributes, along with some classes. In order to do this currently, I would have to pass in the required struct but keep it empty since I don't want to set a defaultvalue
attribute.If I do want to add a default value, I have two ways to do it:
value
attribute (still have to pass an empty struct)I think we can do away with this redundancy since there's already a default way to define the default value of HTML elements. Another issue is that the
val
dictionary being passed into thefield
function is only used to retrieve the value of the field with the same key in the second argument, which makes any other fields in the dictionary pointless to the construction of the input element.Whatever slight benefit that could be gained by reusing a table of attributes for the sole purpose of extracting the
value
attribute is outweighed by the redundant API. Allowing the first method also opens up the possibility for inconsistency in the codebase if the same thing is done differently in different places. Pre-filling input fields is also not the desired default behavior in most cases for non-hidden inputs so an empty struct would have to be passed in most of the time.After this refactor
By default, attributes other than
name
are not set unless done explicitly. There is also no need to pass a dictionary and duplicate the key but simply a keyword or string for thename
attribute and the optional attributes after that. I believe this makes for a much simpler and intuitive API. Here's the code to do the same thing as above.