+1 to everything you said, it all sounds like awesome work : ). Hopefully will be easier to make the front-end code testable as well. Another thing to maybe think about in the future is plugin/customization of the UI. E.g. being able to have custom UI widgets for operators that e.g. visualize data in some way (it's super useful for ML at least). Also not a front-end guy either, but React seems like a fine choice.
On Wed, Nov 27, 2019 at 12:07 PM Ash Berlin-Taylor <a...@apache.org> wrote: > Hi everyone, > > We here at Astronomer are thinking about what we'd next like to work on to > improve Airflow, and one of the most visible ways we could improve Airflow > would be to update the UI, and make it, well, more designed and less > grown-over-time :) > > A non-exhaustive list of things we'd like to fix/improve/add in the UI > > - Making the UI more consistent. For example the actions you can take via > the Browse pages are different to the ones you can take via the Task > Instance modal, and none of those are visible when you're on any of the TI > pages. > - Update the look and feel to be more modern. It's especially noticeable > now that we've redesigned the project website. > - Improve the UX and "usefulness" of the UI. There's lots of power in > there, but some odd quirks in to how information is presented that could be > improved. > - Have "real time" updating of the UI. (This is a biiig chunk of work, > especially the backend component for this and is a whole separate > discussion, but we want to work on this.) > > We build the UIs for Astronomer in React so we were thinking about using > React again here on Airflow. There are a couple of ways we could do this: > > - We could update/redesign/rebuild the existing mostly static pages in > place (i.e. just change the templates/js/css) > - A hybrid approach where we could add react to chunks of the page, but > keep parts of it server-rendered. > - A total re-write where the UI is react-only and the UI just speaks to an > API server. > > The main thing I'm conscious of is avoiding the "dual webserver" we had > with the RBAC addition which caused all sorts of pain, both for > development and for users. I want to avoid that pain again. > > The other thing is that React has a higher learning curve, so if we do > decide on React we should make sure that we have some clear guidelines on > how to structure and test the code, and better yet machine-enforce rules. > > Do people have opinions on React in general (I asked in #sig-ui on slack > and the few people there were broadly positive of React) and the approach > we should take specifically. Normally I'm a bit of a luddite when it comes > to HTML+JS and I like things to be progressively enhanced buuut maybe that > isn't a requirement here.. > > Thoughts? > > -ash
