Todayās Picture of the Day
Since only one dialog appears at a time, Iām thinking itās better to manage them by name rather than by individual boolean.
type TDialog = "" | "AddFusen";
ts
const AddFusenDialog = () => {
const [dialog, setDialog] = useGlobal("dialog");
const open = dialog === "AddFusen";
const onClose = () => {
setDialog("");
};
return (
<Dialog open={open} fullWidth={true} fullScreen={true} onClose={onClose}>
...ts
describe("dialog", () => {
beforeEach(() => {
cy.visit("/");
});
it("main", () => {
cy.contains("Add Fusens").should("not.exist");
cy.updateGlobal((g) => {
g.dialog = "AddFusen";
});
cy.contains("Add Fusens").should("exist");
cy.contains("Close").click();
cy.contains("Add Fusens").should("not.exist");
});
});
By the way, do you want to use Fusen as the name to show to users or not?
- The previous implementation was Piece.
- Postit is a trademark of another company and I donāt like it.
- StickyNote looks long and sticky when itās Sticky.
- Sticker would have a picture on it.
- Iām thinking of pushing through in Japanese.
- I think it would be better to use small stature as a word to express a new concept for Japanese people, away from the existing physical sticky notes.
- White background āwhiteboardā sounds like writing with a pen, while ācanvasā sounds like drawing a colorful picture.
- This too could be a āplaceā for a change.
- Kozane / Ba
- The name of the application itself should be Kozaneba.
Strong will not to let the menu bar monopolize valuable screen spaceā¦
- Do you want more transparency or a darker background color?
menu
- Document
- https://material-ui.com/components/menus/
- It depends on the local state of the component, but itās tricky when you bundle each menu button handler and such into a separate module.
- Last time we created a āclose when doneā wrapperā¦
- In the first place, is the menu one at a time as well as the dialog?
- A child menu is possible.
- In that case, thereās no point in continuing to give the parents options, so why not still have one at a time?
- A child menu is possible.
Menus appear on sticky notes.
- But I donāt like the subtlety of where it comes out.
I didnāt like it, so I fixed it.
-
I feel this should be the default behavior.
-
I canāt specify where to show the menu, so Iām moving the invisible div to the mouse position.
-
-
After reading knee-swing (gymnastics) again, I realized that what Iām making is more like the Kozane method than the KJ method.
KJ methodā¦ The KJ method is highly regarded as a method of āgathering the collective knowledgeā of multiple people, and seems to be put to practical use by various companies. The Kozane method, which I have introduced here, is a closed-door intellectual production technique for a few individuals, and belongs to a relatively simple and elementary technique in Kawakitaās system. In Kawakitaās system, it is almost the same as what is called āKJ method Bā writing.
drag/drop
- I could drag and drop.
- HTML5 Drag&Drop API
- However, it moves the center to the drop position regardless of where you grabbed at the start of the drag, so you need to record the misalignment at the start and compensate for it.
- Maybe I should make a serious test of the conversion between the screen coordinate system and the world coordinate system once I make itā¦
- Iām sure theyāll use it in many places, not just this one.
I implemented a coordinate system transformation but it is difficult to test. The following does not work test.ts
cy.testid("2").should(
"hasPosition",
movidea.world_to_screen([top, left])
);This is because the coordinate transformation is processed first at time T1. Even if we retry asynchronously later, it is meaningless because the ātarget valueā has been calculated and fixed earlier. test.ts
cy.testid("2").should(
"hasPosition",
T1
);To retry the coordinate calculation itselfā¦ I thought about it and put it in then. test.ts
cy.testid("2").then((el) => {
return cy
.wrap(el)
.should("hasPosition", movidea.world_to_screen([top, left]));This still doesnāt work if the last state update is asynchronous, I had set the default asynchronous, but decided to make it default synchronous and only specify the option when asynchronous is needed, for some reason, all tests passed even with synchronous.
Postscript of the next day
- If you think about it, this is due to the fact that both screen drawing and coordinate transformation depend on the ācurrent stateā, so it would have been better to have a pure function that explicitly passes all the necessary values for coordinate transformation.
When dragging by grabbing off-center, the second drag is inexplicably misaligned, or the center drag, which is supposed to return to the original position, does not return to the original position at all.
- I was wondering what was going on when I was testing a drag in Cypress, and I noticed some inexplicable misalignment. The coordinates must be off because the Cypress UI scrolls to display the object when it is dragged nextā¦
- So, even in apps with overflow: hidden and wheel events preventDefault, Cypress scrolls to show the drag target, so I should have used pageX instead of clientX?
- Thatās not rightā¦ Even with that fix, the āinexplicable behaviorā reproduces itself.
- For now, we know that it works as expected in the test case without overflow, so letās separate the behavior when it overflows as a description of the current behavior.
- I decided to let this case go through, because I operated the pattern of sticking out by hand and it worked as expected without any problem, so there is no problem in human use of the application I wrote, only that it behaves strangely when Cypress uses it.
Can now grab and drag off center.
- The first time it strikes out, itās because the window wasnāt in focus.
This page is auto-translated from /nishio/2021-07-15Movideaéēŗę„čØ using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. Iām very happy to spread my thought to non-Japanese readers.