Table of contents:

1. 💸 Swish payments
2. 🧾 Receipts
3. 📸 Snapshot testing
4. 🎉 Removing Material UI
5. 🪦 Shutting down the old sign service
6. 🔍 PDF zoom bug

💸 Swish payments

Swish will soon be added as a new payment method on invoices from senders connected to Swish. This is one step in improving the overall payment experience for our users. As well as making the senders happy by potentially having their invoices paid earlier!

Implementing Swish on the web has been in the works for the last two sprints and is now starting to come together.

Helped by the mock-server

Since we have our own “mock-server” it meant we could start development early on without having to wait for the related back-end work to be finished. As the name implies - the mock-server is a service replicating some of the endpoints and functionality found in our backend services. Not only does it help us when developing but also gives us benefits when running tests since it means we can run tests in isolation as well as mocking external dependencies, in this case Swish. An example of this is how we´re able to “fake” user interactions with the Swish app by simply making an action using the mock-server´s user interface. This let´s us develop, as well as easily run end-to-end tests without having to rely on the Swish app.

To better get a feel for how it´s used in real life we have put together a short video where an invoice is created and later paid with Swish, enjoy 🐣.

🧾 Receipts is finally in Sandbox

Receipts have actually been live in sandbox for some time now. And during the last few weeks we have been working on resolving bugs that we and other helpful peeps have noticed.

End to end type safety

As you may have heard before we are using the BFF to massage the receipts into something that is more easy to work with on the web. And the BFF is a GraphQL server which means that everything that clients ask for, is strictly typed in runtime. But in order to know what data the BFF can provide to the clients, the BFF must also know what data to expect from the backends.

**Documentation entered the room**

The usual workflow for us in the web teams is that we look at the documentation and then we make TypeScript types out of these. Then inside our client code, we can easily see what data to expect from our different endpoints. But, there is a catch… TypeScript is only type-checking during the compilation (not in runtime).

**Zod entered the room**

Zod is a library that provides us with runtime validation and TypeScript types. So, we are using that to create schemas that validate the data we get from our backends. The only downside is that complex nested validations takes time, so much so that we see that it slows down the requests. So for now we are disabling the runtime validation in production, but we are still using it in sandbox and when developing locally.

In all honesty, Zod has probably saved us more than a dozen times already due to us reading documentation wrong or the documentation being wrong. Zod will tell us whenever the data mismatches with the schemas we have set up. So it is really an awesome addition to our stack and it helps us provide end to end typesafety.

Please ping us at #team_web if you find anything or have any questions.

📸 Snapshot testing

In our project called React components (this is where we store our reusable components), we have snapshot tests. Snapshot tests is a kind of test which takes screenshots of the components in the project and compare them with already existing snapshots when something new is added or changed in the code. This is very handy to see if any unwanted changes has happened during development. This is at the moment done with help of a test runner called Cypress.

Unfortunately we have found some drawbacks with Cypress:

• It is slow
• Tests has been flaky (failing sporadically)
• Do not support M1 mac
• Have bad support to run the tests of a remote machine
• Only support Chrome

We also would like to align our use of test runner with other projects. In our inbox project, we have been using Playwright while developing receipts, and we like it alot. So this is why we are re-writing all of our current tests from Cypress to Playwright.

The only drawback with Playwright is that it does not support this kind of tests 😬 So we wrote our own test pipeline

Here we have intentionally changed the text of button in one of our snapshot tests, and this is the output of the test, which obviously failed.

Actual snapshot

Expected snapshot

Difference between actual and expected snapshots

🎉 Removing Material UI

We have had a dependency to Material UI (an external component library) for a long time. This do however blocks us to implement some upcomming features. We are therefore working on removing all dependencies to Material UI. This is a lot of work but we are getting closer to being done with this.

🪦 Shutting down the old sign service

We have now shutdown the old sign service and it is no longer possible to neither sign or upload any new signatures

🔍 The PDF zoom bug

In some browsers and devices we have gotten reports that zooming sometimes causes the PDF to go blank. We have been able to reproduce it, and we have a solution in place to make sure zooming works as intended.