Closed layflags closed 7 years ago
Yeah, but what about when you want an event handler that does start with "on[A-Z]"?
Yeah, but what about when you want an event handler that does start with "on[A-Z]"?
we could use the convention of defining event handlers like [... "onFoo()"]
instead of [... "onFoo"]
... makes it clear to the reader, no?
Very interesting idea with the name convention. That would mean dropping all types and only passing the array right? Can you think of any causes when you might need custom serializers? I think with JSON you can pretty much cover everything.
Benefits for the types would be improved speed and more control. Then we wouldn't have to differenciate onFoo
and onFoo()
.
It really just depends on what we want to expose. So I think it is also fine to have a quick start solution with the array. And offer the mapping for advanced usage.
Very interesting idea with the name convention. That would mean dropping all types and only passing the array right?
Right :)
Can you think of any causes when you might need custom serializers? I think with JSON you can pretty much cover everything.
I've to admit that the custom serializers are not really necessary, let's KISS. We can implement this feature when it's requested as hell ;)
Benefits for the types would be improved speed and more control. Then we wouldn't have to differenciate onFoo and onFoo().
True, but there's space for optimization even for the Array solution. The parsing of e.g. "onFoo()"
would just happen in the register
call, not on every render
It really just depends on what we want to expose. So I think it is also fine to have a quick start solution with the array. And offer the mapping for advanced usage.
<3 KISS ... I think there's really no need for the Types
anymore ... seems like we switched preferences, heh? :D
Merging and continuing API in new PR.
Now the mapping short form is nearly as good as the type mapping. What do you think? Ditch types? ;)