briandipalma

var getAmount = (e) => e.querySelector(".text-right").innerText.replace("€", "");
var parse = e => parseFloat(getAmount(e));
var tbody = document.querySelector(".transactions-data-table tbody");
var entries = Array.from(tbody.children);
var amounts = entries.map(parse);
var mostRecentYearly = amounts.indexOf(110.00);
var lastYearly = amounts.indexOf(110.00, mostRecentYearly + 1);
var yearlyCharges = amounts.slice(mostRecentYearly, lastYearly);

yearlyCharges.reduce((a, v) => a + v, 0);

briandipalma

  // Available variables:
  // - Machine
  // - interpret
  // - assign
  // - send
  // - sendParent
  // - spawn
  // - raise
  // - actions

briandipalma

When working with React components that have async data flowing into them either via single requests e.g. fetch calls or via a WebSocket connection/subscription state created with useReducer that is initially based on component props can become stale/incorrect as the data flows into the component and updates the props.

Also JSON.parseing data that flows in from a connection will create new objects even if the strings being parsed as the same each render. This can defeat useMemo and cause infinite rendering loops even if your useReducer reducer returns the same object on each call.

Returning null from a component triggers useEffect clean up code.

If in your action handlers you need to do more than just dispatch, like call a parent callback to provide a controlled value update then you can still use contexts to provide dispatch but you will just need to also passdown the parent callback/reducer required state that is provided by your parent. Overall it will result in fewer functions on

briandipalma

Thoughts on web component development.

Firstly a definition.

A web component is a widget that a user interacts with in a web application. The complexity of the widget does not have to high, it can be as simple as a single button. Best practice would be to create more complex components by composing simpler components.

What's involved in developing one.

briandipalma

A discussion around the client side stack, the current approaches taken and possible value of new technologies and standards. How broadly applicable is our stack and approach to others and the pros and cons of maintaining it. If it's even feasible to ever replace parts of it, or worth it. Also theorize on what choices a competitor would make.

---

The reason for this meeting was Paul Caplin wanting to understand where BR fits into an average, current front end tooling stack. The value of BR and the other open sourced projects, for average web app developers, has been questioned by some of the JS devs, including myself. Most of these points have already been covered in the emails I've sent out, so apologies for the repetition.