[Koha-devel] To React or not to React

Wed Sep 21 17:03:33 CEST 2016

Hi there!

I don't know how I intercepted this email since I never read my email, but...

"In all seriousness, I just want Koha to be the fastest, slickest most useful ILS in the world. I want it to be an absolute pleasure to use. And I think this is a necessary milestone to achieving that goal."

Kyle. I totally f***ing agree with you 10000%.
Swagger2 + React + Redux will f*** the s*** out of any ILS Koha meets.
Not to forget javascript BDD, PageObject and good test infrastructure to rapidly deploy test contexts and tear them down easily and efficiently. Regression is the worst PITA with Koha atm.

I am looking forward to kopypaste the React + Redux framework the Oslo Public Library uses for their Library System Extended, but there are many great examples on how to put React + Redux to good use in Github. And most importantly many great examples on how to easily and effectively test all the components.

I was planning to start a completely separate namespace (or project) 'KohaFi' for this so we can get rid of the legacy baggage and use only the REST API to move data from Koha to the newly branded KohaFi ;) (naturally reuse the good bits from old Koha to explain the obvious)
We can leverage browser storage to speed up all kinds of system preferences and caching stuff.
Rewriting one page/module at a time while still using the old Koha with url-redirects to fill up functionality not yet put under KohaFi.
Taking a completely new approach to how i18n is done. Translation straight from the GUI.
Rewriting most of the Koha internals effectively and putting everything under regression testing to maximize speed and verify API version immutability.
Rewrite MARC::Record as a XS-module maybe?
It would be good to separate the REST API with RabbitMQ from the core Koha so we can have sturdy transactions atleast there where those are needed (epayments).
Start using HTTP2.0 or SPDY
Use NodeJS and Ecmascript6/7 with Babelscript.
+++
There are so many things modern web development practices would improve in Koha.

Ofc before we (as in Finland) can start working on that I have a ton of stuff to do. Maybe next year we can hopefully work on this after we have migrated to ElasticSearch and the newest Koha-community version and gotten rid of the horrible Zebra and some self-service library automation project...
Personally I see this as the only way for Koha to get rid of its legacy baggage, make it a good system and actually make working with it a pleasure. And if I have to take this route alone, I wont blink an eye for I know only success lies there.
Looking forward to working with you.

OAK

________________________________
From: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] on behalf of Kyle Hall [kyle.m.hall at gmail.com]
Sent: Wednesday, September 21, 2016 5:27 PM
To: David Cook
Cc: Koha Devel
Subject: Re: [Koha-devel] To React or not to React

On Tue, Sep 20, 2016 at 6:29 PM, David Cook <dcook at prosentient.com.au<mailto:dcook at prosentient.com.au>> wrote:
I think it differs in that a search engine and a RESTful API adds core functionality. Without them, we can’t really search or expose services. We already have a JS UI toolkit, which seems to be working fine.

Yes, jQuery UI does work just fine, however libs like React really solve a different problem domain. In fact, it's expected that jQuery will be used within React for API access.

Why do you say that React is necessary and long overdue? In terms of your email, do you mean that it lets you do more with less code? I’m not necessarily opposed to that. I do get annoyed by having to write so much code to achieve small things at times.

That's the problem React solves! I takes *so* much less code to write an equivilent feature with React than it would with html and jQuery dom manipulation. I was actually a bit shocked at how fast I was able to rewrite the item messages feature in React.

I suppose I’m curious as to the motivation behind React at this point. Aren’t there higher priorities for Koha right now? I suppose maybe that’s just my own naïveté speaking, and part of the joy of having so many developers on Koha is that we can all focus on different aspects of the system.

That's the great thing about Koha as a community. Koha has no priorities, but each stakeholder can. I'm sure your priorities could be much different from my, but they can be pursued simultaneously!

Yet, shouldn’t there be some cohesion? Are our interfaces going to be a combination of plain JS, jQuery, Bootstrap, React, Yui (if it’s still used), and whatever other libraries we’re still using? This is what I mean about bolting things on.

Then again, if React really does allow for cleaner interfaces, perhaps we’d find it taking over our interfaces rapidly, and it would become a de facto standard. I don’t know.

There's only one way to find out ; )

In all seriousness, I just want Koha to be the fastest, slickest most useful ILS in the world. I want it to be an absolute pleasure to use. And I think this is a necessary milestone to achieving that goal.

Kyle

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

From: Kyle Hall [mailto:kyle.m.hall at gmail.com<mailto:kyle.m.hall at gmail.com>]
Sent: Tuesday, 20 September 2016 3:31 PM
To: David Cook <dcook at prosentient.com.au<mailto:dcook at prosentient.com.au>>
Cc: Owen Leonard <oleonard at myacpl.org<mailto:oleonard at myacpl.org>>; Koha Devel <koha-devel at lists.koha-community.org<mailto:koha-devel at lists.koha-community.org>>

Subject: Re: [Koha-devel] To React or not to React

For my part, I don't know if we need to keep bolting on more new and shiny
to Koha.

ElasticSearch makes sense. A REST API makes sense. Fixing broken things or
adding missing essential functionality.

I'm not sure how this differs from Koha adding Zebra, adding Elastic or adding a restful api. To me, this is not a matter of adding new for the sake of new ( React isn't even new at this point ) but of adding something that is necessary and long overdue. The question isn't about needing React or not, it's about the need for a modern JS UI toolkit to take advantage of our svc and rest api's without the need to write crazy amounts of code to make it work with just jQuery. Take a look at the javascript file for the holds table and you'll see what I mean. A React implementation of it would be *so* much cleaner and easier to understand for everyone. Please don't ask me to rewrite it as a poc though ; ) I *will* be happy to rewrite it post-adoption.

Also, how would this React POC go in terms of translations?

React is just Javascript, and is translated the same way translate all our other js files.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org<mailto:koha-devel-bounces at lists.koha-community.org> [mailto:koha-devel-<mailto:koha-devel->
> bounces at lists.koha-community.org<mailto:bounces at lists.koha-community.org>] On Behalf Of Owen Leonard
> Sent: Monday, 19 September 2016 11:33 PM
> To: Koha Devel <koha-devel at lists.koha-community.org<mailto:koha-devel at lists.koha-community.org>>
> Subject: Re: [Koha-devel] To React or not to React
>
> > Another thing is that you need nodejs to compile it so is another
> > thing to throw on the stack.
>
> Isn't this the kind of dependency requirement that killed my request to
> introduce a front-end build tool like Grunt or Gulp?
>
>   -- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org<mailto:Koha-devel at lists.koha-community.org>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : http://git.koha-
> community.org/<http://community.org/> bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160921/d364fa43/attachment-0001.html>