From March 12th to 15th, we hosted a
at our office in Bonn. The main goal of this three day sprint was to contribute
back the work we did for a recent client project. We also planned to upgrade
Plone-React to React 16 and improving the error handling.
A small and very focused sprint with the core contributors of Plone-React was
the perfect opportunity to do so. Participants were Rob Gietema, Roel Bruggink,
Asko Soukka, Victor Fernandez de Alba, Carsten Senger and me.
Sprint Day 1
We started the first day of the sprint by doing a quick stand up and planning
meeting. We used the days before the sprint to outline our main goals and
objectives, so we could get started right away.
Planning board after the stand
On the first day Rob and Victor worked on
upgrading plone-react to use React 16
and Webpack 4.
We postponed the
upgrade to React router version 4,
because some of the dependencies that we need, are still in alpha phase and
staying with the old version does not hurt right now.
Card to upgrade to React 16
The main reason why we were eager to upgrade to React 16, was a
new feature called “error boundaries”,
which allows catching errors in React components and handle them gracefully,
without failing the entire app.
error boundaries for client and server side components and for the Redux middleware.
It is also possible to pass those errors to Sentry for aggregation and further
Since we are about to launch our first Plone-React-based project in the next
weeks, this was something that was especially important for us.
Error message in plone-react
Token Expiration Middleware
Rob added a
token expiration middleware to plone-react
that improves the handling of JWT auth token in Plone-React. Working with
plone-react on a daily basis revealed a few edge cases where the current
authentication failed. The new middleware solves those issues.
Roel and Carsten focused on plone.restapi. Even though this was not planned to
be a major topic for the sprint, we had to fix some issues that were causing
troubles in the Plone-React frontend.
Carsten worked on fixing an
issue that was preventing to allow the API consumer to reset field values to “None”.
Roel started to work on
exposing widgets with tagged values via plone.restapi.
This is necessary to support autocomplete or reference widgets in Plone-React.
Asko, who joined the sprint remotely, worked on a brand new end-to-end testing
setup with Robot Framework. Because this would be way to easy for a super-smart
guy like Asko, he decided to wrap the components into a Docker containers, to
make it easier for non-Python devs to set it up. Making Plone PIP-installable is
also something that we want to have for quite a while. Asko decided to also mix
that in. To make this fun, he decided to add support for Jupyter notebook, which
makes it super easy to write Robot Framework tests.
Hangout with Asko
I started the day discussing the acceptance testing setup with Asko, quietly
listening to Rob and Victor and discussing the plone.restapi issues with Roel
During the first day, we started a discussion how plone.restapi could support a
toolbar that automatically adapts to the permissions of the logged in users and
shows only the actions that this particular user has permission for.
Before the sprint Victor worked on implementing the new super fancy adaptable
Pastanaga toolbar, and we were eager to build a proper backend implementation
Victor's tweet with a short demo of the new Pastanaga toolbar
Sprint Day 2
On the second day of the sprint, Rob and Victor started to look into building a
“create-react-app”-like functionality for Plone-React.
create-react-app is a widely
popular code skeleton generator by the React team at Facebook. It hides lots of
complexity from the user (e.g. Webpack, libraries, configuration) and makes it
easy to get started with React. This is super important for the adoption of
Plone-React because it also allows to use Plone-React as a library and basis for
custom client projects.
Rob and Victor created a proof-of-concept that kind of works but it became clear
that this requires a lot more effort before this becomes ready-to-use.
We scheduled a time slot for a discussion and planning session about the new
“Pastanaga editor” user experience. We already implemented basic text editing
based on the DraftJS editor from Facebook. The current
editor allows basic text editing as well as inline (italic, bold, etc.) and
block styles (e.g. headlines, bullet points) and external links.
The next step on our agenda to make this editor based on Tiles to make it
extendable and allow the user to add images, videos and other media objects.
We agreed on moving forward with an agile approach of building something useful
step-by-step, making sure to build a fully functional and useful editor at any
point of the development stage, rather than building the full Mosaic-like
functionality at once.
Right after this was settled, we started to draft a tiles endpoint that would
build the basis for the next iteration of the Pastanaga editor.
Rob started to work on implementing the context-aware toolbar. This was a
challenge because the toolbar needs to adapt to the content that is shown in the
main column. This means a component deep down the component hierarchy (content)
needs to be able to update a component that lives outside of the DOM hierarchy
of the parent component. Luckily for us,
“Portals” in React support exactly that
Victor worked on the flexbox styling of the toolbar as well as on optimizations
of the Webpack configuration.
plone.restapi, Tiles, and Testing
Roel and Carsten continued to work on plone.restapi issues. Roel continued to
work on the tagged values representations and Carsten finished the actions
endpoint for the context-aware toolbar.
I followed our established documentation-first approach on plone.restapi and
docs for the new tiles endpoint.
With the basic test setup already in place, Asko struggled with the Travis CI
setup running different versions of Node and Python at the same time. Problem is
that the ZEO version requires the latest Python 2.7.13 which is not shipped by
default with Travis CI.
He also worked on a Docker compose option to support an option to run the API
server. This would allow faster development of Robot Framework tests since the
API server does not need to restart for each test (iteration).
Sprint Day Three
We started the last day of our sprint discussing the create-react-app use case
we worked on the day before. Afterwards, we did a hangout with a student who is
interested in working on this during the Google Summer of Code 2018.
Hangout with a possible Google
Summer of Code student
Right after this call, Asko gave me a tour of the new, Docker compose based,
PIP-installable, Jupyter notebook enhanced test setup.
My head was still spinning from Asko’s amazing work, when Rob asked me for a
minute to show me a prototype of the new Medium-like Pastanaga editor.
The sprint was extremely productive and fun. Having a small and dedicated group
of developers with a clear goal and focus really worked well for us.
Group photo in front of the
We contributed back all our re-usable code from our client project, upgraded
Plone-React to React 16. We fixed some important issues in plone.restapi and
build a super fancy test setup that will allow us to further improve the
software quality of Plone-React.
We also laid the groundwork for the next important steps forward: Building the
new Pastanaga editor with a tiles-based backend and allowing to use Plone-React
as an extensible library with a “create-react-app”-like functionality.
We are already looking forward to the upcoming Beethoven Sprint and the Costa
Brava sprint where we will continue to push Plone-React, Pastanaga and