https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201
--- Comment #5 from Pedro Amorim <[email protected]> --- Thank you for your time here, Joubu. Your feedback is obviously very important and valuable. We are going to fix the bugs you have raised and are still finishing this up, some things still require polish (some of this code was written as recently as today). Having said that, we're very grateful you've had the chance to review it right now. (In reply to Jonathan Druart from comment #4) > > 8. With the additional abstractions everything is harder to read IMO, we > should add documentation, at least for the "Base" components. Yes, we plan to have documentation here but we've not gotten to that point yet. It will be great to have Koha developer documentation once we have this established pattern in place, to help guide new developers on how to setup their own VueJS module. (In reply to Jonathan Druart from comment #4) > > Overall I think the idea is good but it adds some "magic" that won't help > new developer to grasp our VueJS code. I feel like you have been too far, > and things won't be as easy to maintain as you think. I'm really happy to read that you think the idea is good! In terms of maintainability, I have to disagree. Particularly developing bug 37893 (which is a new full VueJS module), as a module implementer I have close to zero implementation work, as all the heavy lifting is already done for me and I have much less code that I need to write, thus much less chances of adding new buggy code. We believe VueJS is the direction of travel in Koha development. Our goal is to ensure consistency on every existing and future VueJS module, something that does not happen in the rest of (old) Koha. We want developers going forward to invest as little time as possible in: - Implementing the 'create' routine of a 'Resource' - Implementing the 'delete' routine of a 'Resource' - Implementing the 'edit' routine of a 'Resource' - Implementing the 'show' (read) routine of a 'Resource' - Implementing a relationship form element with relational fields - Implementing a relationship form dropdown element - Implementing a 'date' form input element - Implementing a toolbar for their module - Implementing a table - etc All these things should only be implemented ONCE, and maintained in a single place. This work is not there yet but that's our goal. I agree that some of the 'magic' could be less obscure, but this is not final (nothing ever is) and we expect to iterate on this long after it's been pushed to core. We want developers to invest time in the actual features their module should have. Not all the boilerplate. By having all the modules share the same base components, we ensure far less bugs and establish a new coding paradigm that will encourage developers to implement new functionality at the 'Base' level whenever they need to do so, in a way that every other developer can also make use of it, instead of doing these things on their own specific module form, button, etc. Thanks again, we'll come back when this is ready for review. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
