Implement UI testing

[TobiTenno]

on #2 @tukusejssirs and @TobiTenno discussed removing jest testing and moving to a pure UI testing system like cypress or playwright

we can discuss what we want to implement here and compare how they'd fulfill our needs. the final choice, we'll document at the end of the issue

[TobiTenno]

@tukusejssirs i'm biased towards cypress because I already use it a good bit and it supports verbose component-based testing. i've not looked into playwright much yet

what are the benefits you see for it?

[tukusejssirs]

Use whatever you want. Either is fine with me, I have just read that Playwright might be better/preferred these days, however, I am not a frontend dev. :man_shrugging: If you already know how to use Cypress and consider it a good UI tester, I won’t stop you from using it in here.

That said, I do think that for actual unit tests (e.g. functions, methods), Jest does a good job, however, not for UI tests. As I see it, Cypress is more of an integration/e2e tester. On the other hand, this package might not have much code moved into classes/functions moved outside of a component, thus removing Jest altogether might make sense.

Therefore, I let you do it the way you consider the best. :pray:

[TobiTenno]

i'm fine with jest for, say, the library itself, but on this example app, given that we're not testing the functionality of a pure-code (i.e., unrendered, not something in the browser itself); I think we should scrap jest altogether specifically on the UIs in this repo. If we want to use Jest for, say, the API, i'm totally down for that.

[tukusejssirs]

Okay, go for it. :pray:

[TobiTenno]

@tukusejssirs & @emagnier I've been trying to speed up the load of the expandable day variant as part of this, cause it's really slow switching months (at least for me?).

particularly, @emagnier, what specific component are you using on https://romcal.js.org for the pretty json print? It loads very fast and still has the features I'd like to see, but on all of the rich viewers i've tried, they result in very slow loads if they're at all interactive.

I've tried loading the components w/ react's lazy, but it does next to nothing to help load time on first load and switching months.

Additionally, i'm planning on ejecting and switching to vite for a smaller footprint from react-scripts that we can give as a better example for keeping up-to-date & more freedom to have all of the build configs less annoyingly locked down in the way that react-scripts is.

---

Small update: running @microlink/react-json-view in the production build is definitely faster, but not as fast as yours.

[tukusejssirs]

it's really slow switching months (at least for me?).

For me, it is fast (after the initial loading OFC) for both NPM and PNPM. I have tested this on 2f44d36 and I have tried it on different combinations of locales and calendars. :man_shrugging:

However, I am not sure what you mean by expandable day variant. If it is not started by npm start and/or there is a special config for this, I might not test this correctly.

[TobiTenno]

If you look at the readme, I added a variant for displaying the day's json data, like in romcal.js.org to help us get closer to having that open sourced and easier to deploy after version updates, as our exemplar page is outdated (beta 37, I think) and buggy (time bug that I fixed on here) for negative UTC offsets.

So if you run REACT_APP_DAY_VARIANT=developer npm start, the page load time will change. I've migrated it on my branch to Vite, so it works a bit differently there, but I'm working on figuring out why the pretty json viewer is slowing the month switch down.

[TobiTenno]

@emagnier still looking for your feedback, since i don't have the base code for romcal.github.io

[tukusejssirs]

Isn’t this the source code for romcal.github.io/romcal.js.org? 🤔

Actually, it seems to be the compiled code.

[TobiTenno]

yeah, that's the problem. i can see class names and stuff, but not actual component names

[emagnier]

Yeah, sorry for the delay. The code on romcal.github.io is indeed a derived version of the React example from this repo. The JSON viewer used is this one: https://github.com/uiwjs/react-json-view.

I did it quickly and quite experimentally, so the setup is almost non-existent. Indeed, the compiled code here https://github.com/romcal/romcal.github.io is what serves the website (plus the CNAME file for the js.org domain). For your information, I've just pushed the source code to the source branch of this repo.

Clearly, there are certainly things to automate here (like with every new npm publication of romcal, for example).

[TobiTenno]

@emagnier is it a much older version? either way, they seem to have the same issue I do for the most part of slowness transitioning between months & initial slow load (at least on my branch).

If you have time to look, I'd appreciate your input, i'd happily open another PR to make it faster.

Update: I've got it figured out, my use of lazy and not using the transition props you used were:

• causing slower loading of the AccordionDetails
• causing crashes by using lazy when i added the transition props

so it should be much faster on #6

[TobiTenno]

once i finish #6, @emagnier, i believe i'll have everything in place to prep CI for automated deploys from the PR merge

[emagnier]

Related to the last comments https://github.com/romcal/romcal-examples/pull/7.