-
Notifications
You must be signed in to change notification settings - Fork 37
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
Allow editing of defined DOM properties #35
Conversation
I'm working on tests next, and will add some for this there. But if you want, I can also add them into this pull request |
a814d82
to
ba17c6d
Compare
Currently this doesn't ignore null as the readme suggest, but I'll fix that in a follow up pr (or tomorrow) |
ba17c6d
to
88baf5b
Compare
I would not like to allow the properties object in any other position than the second argument, it increases the surface area for testing, does not add any usability, and would probably decrease understandability. Also, to implement this, there are multiple additional duck-typing checks per child added. This would likely have a notable impact on performance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm missing some tests, as these changes should fail tests. I'll have a look.
These changes should fail this test: https://github.com/KoryNunn/crel/blob/master/test/index.js#L149 But there are too many conflicts for me to easily check this. |
88baf5b
to
e387640
Compare
Yeah, my original use case for that became obsolete, so I'll look into it after a rebase |
e387640
to
ef952a8
Compare
Rebased! No longer allows for multiple attributes objects to be passed. I also tried to make the changes a bit more incremental |
} else if (isType(attribute, fn) || element[key]) { | ||
if (isType(attribute, obj)) { | ||
// We only check and allow for one level of object depth | ||
for (value in attribute) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a helper for things like the style object? This is not really the intent of crel
which aims to be extremely simple and raw. This is something that could easily be implemented in a more feature-rich module that uses crel under the covers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't crel there to allow creating and editing ALL of the basic attributes and properties of an element? That's why I added the properties manipulation anyways. And with that in place it becomes kind of impossible to edit the style of an element through crel, because you can't access the attribute anymore.
On a side note, it's not specifically a helper for the style property, but then again I don't know if any other property is nested like that.
3d5b2e1
to
81b94b6
Compare
Rebased. I split this into multiple prs. Currently based on #42, only adds the property changes. I'll open another pr for the invalid argument handling at some point |
ee1a493
to
d86452a
Compare
d86452a
to
493bde6
Compare
493bde6
to
d84b181
Compare
final rebase |
No problems. Would you be able to let me know which of the other PRs I should look at and in which order? |
Ok, take number
23!Now only changes element property handling and adds tests for it.
Crel now prioritizes element properties, if they're already defined, over adding / modifying attributes. This way you can edit properties like
style
orinnerHTML
, etc. using Crel, without having to use attrMapThis does remove the ability to use some reserved keywords in attributes, if you can't be certain that they are undefined, but I think that's bad practice, so we shouldn't encourage it anyways
Also updated the README to reflect these changes