Frontend Decision Board meeting: 2019-10-09

[varl]

Hey gang (@dhis2/front-end) 👋

It's been a while since the last decision board meeting and it is time for another round of trying to get a rough consensus around some discussions.

Feel free to suggest additional topics to settle.

Agenda

General notes

• Help each other stay on topic in a discussion, split side topics into new issues

Discussions to settle

Slow down releases a bit, improve automation

Dependabot is great, but it is tough keeping up with Dependabot right now.

By slowing down automated releases a bit we can improve automation and bundle more bug fixes and features into the same release of our libraries.

Proposal:

• Introduce a develop branch that is used as base for development
• master branch is the production branch
• feature branch is created from the develop branch
• feature branches are squash merged to develop
• develop to master is done with a standard merge to maintain commit hashes between master and develop
• allow Dependabot to automerge certain updates to develop

Pros	Cons
➕ dependency updates by dependabot can be automatically merged to develop	➖ more complex workflow
➕ this applies to libraries for now, apps are a different beast	➖ a release needs to be initiated manually
➕ bundle more than one thing in each release
➕ easier to handle next branches (they are very manual labour intensive atm)
➕ instead of slowing down Dependabot, we can allow it more automation

ESlint config generated by d2 style js install #52

• From version 4.x of d2-style it is possible to extend and customize ESLint configs
• d2-style supports different configuration templates:
  • npx d2-style setup linter/eslint
  • And more can be added, e.g. npx d2-style setup project/react
• Open question is how to handle dependencies, should they always be bundled in d2-style (larger install in node_modules or should the setup command list the deps that needs to be installed in the app?

Unified form handling #25

Take a look at the implementation in: https://github.com/dhis2/ui-forms

Some notes we discussed during @HendrikThePendric's presentation of ui-forms:

• Fully formed, un-opinionated, form-field components are to be exposed from ui-core. These molecules are composed fully of ui-core atoms and contain no styling. As a naming convention we use the Field suffix, i.e.:
  • Input represents the ui-core implementation of an input element
  • InputField is an input with error-text and help-text, all wrapped in a Field
• ui-forms is not a form-library itself (yet). Instead it exposes a set of components, validators and formatters/parsers to be used with React Final Form (RFF). This decision was made for the following reasons:
  • Developers don't have to learn a specific form API, knowing RFF is enough (and probably good working knowledge of Redux Form will go a long way too)
  • This keeps the scope of ui-forms fairly narrow, so we can move quickly, because there are a lot of form components needed.
• Ultimately ui-forms is to expose RRF compatible versions of all of the components listed here: Required component set ui-forms#25. Most of these are going to be based on ui-core components, but quite a few others will come from ui-widgets
• ui-forms wraps and re-exports React Final Form (RFF) components, because:
  • This offers some convenience for developers because they only need to add a single dependency.
  • It also provides a level of control in terms of versioning and perhaps providing custom implementations in the future.
• The components exposed from ui-forms are meant to be used as the component prop of a RFF Field, see RFF docs:

  <Field label=”Upload avatar” component={FileInputField} />

• To map the FieldRenderProps that a RFF Field supplies to a framework-agnostic component in a consistent way, we have introduced a FieldAdapter component. We expect to be able to use this for the majority of components in ui-forms.

[Mohammer5]

I hope my internet connection will work just as fine with hangouts as on Monday.
In case it doesn't, I'll add my thoughts here:

Slow down releases a bit, improve automation

I absolutely agree, Dependabot's pace is a bit too fast to keep up with. I'm accepting PRs on a daily basis, sometimes it's 20 PRs per day.
It's already nice to be able to just "Accept" and write "[at]Dependabot squash and merge" (or just accept with @varl's changes in the future), but it still requires a lot of manual work every day.

allow Dependabot to automerge certain updates to develop

So given we accept the proposed workflow (which I'm 100% for!), I'm wondering whether we could merge all non-breaking PRs automatically into the "develop" branch if the build is successful. Once we've completed functional tests with cypress, we'd also know that the libraries are working in the browser (hopefully in more than one soon)

---

feature branches are squash merged to develop

I'd like to loosen up this rule a bit. I sometimes find myself adding 2 or 3 features at the same time, which I only noticed during development. It'd be nice to be able to squash my commits into 2 or 3 commits and then just do a regular merge. In most cases this probably won't be necessary, so I'd like to keep "squash and merge" as the default, but not enforce this.

---

Cons - more complex workflow

I think we can all handle this 😄

ESlint config generated by d2 style js install

I don't really have an opinion about this yet

Unified form handling

As I've been involved in the decisions made about how to set up this library, I currently agree with all points said. I don't think there's anything I want to add (good summary @varl @HendrikThePendric!)

[Mohammer5]

As @varl has limited the scope of this meeting, I'd like to add some points for the next one:

• How to continue with the new maintenance app
  What's the current status in terms of priorities on this one?
  (We're close to start developing sections)

• I'd like to advance the error reporting topic
  This is not purely frontend as it involves the backend and QA as well.

  • Do we already have a plan? If yes, where?
  • If no: Let's add an epic, schedule a meeting and talk about it
    I think this is quite crucial as we have no idea what's happening in the real world until someone reports an error

[varl]

As I've been involved in the decisions made about how to set up this library, I currently agree with all points said. I don't think there's anything I want to add (good summary @varl !)

Actually @HendrikThePendric updated those points, but it indeed a good summary. 👍