Closed Void-0 closed 5 years ago
You're right, I'll have a thorough look at all the properties and make them protected where it makes sense!
:tada: This issue has been resolved in version 1.9.2 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
I've been working with fate a little lately and I really love the extendability of this module as you can customize most stuff with a personalised service. The problem I encountered though is when I wanted to make the FateInputComponent do some specific stuff it wasn't meant to do because our project does some pretty non standard stuff from time to time. In Angular you can easily take component A and extend it in B and have B just re-implement the @component decorator as well as override any properties/methods you want and you get your custom case specific second component without having to duplicate code.
For example, in our project I tired adding some custom event listeners on keypresses. Using el in my child class was impossible since it was private and not protected, so I had to save el as a second property elem in my child class and then get the query selector again basically duplicating some code because I didn't have the access to private properties of the base class. Same with restoreSelection(), as it's a private property it's impossible to use it the child class even though it can be pretty useful.
Those are just some quick example of the top of my head but the more I look at the code the more I'd really appreciate it if most if not everything in that component was at least protected instead private. This would also enable us to make custom getters and setters for stuff we want to expose to some parent components trough viewChild. So, are there any reasons why those properties must stay private instead of protected ?