Mar 9, 2021 08:03
I currently have a huge problem regarding my spare time: my wife wants to renovate the living shit out of our apartment and that means I will not have a free weekend for the next 3 month. So I would want to fiddle about with the fork I have, but I cannot say when I will find some time
Mar 9, 2021 08:01
And about that svgr issue: I looked into the documentation and could find nothing about adding a custom class. But -I know now I get a bit on the overengeneering side- ou could add a second loader in your webpack config just infron of the svgr loader, and that second loader adds the desired class before the svgr loader turn the SVG into a react component. I will try that some day.
Mar 9, 2021 07:59
So they are synced without triggering a re-render of your app
Mar 9, 2021 07:59
But that would mean that the component is re-rendered every 500ms. I thought there might be a way to just toggle a css-custom-variable instead of the local state. and have the css animation triggered by a change of that variable.
Mar 9, 2021 07:57
@bzrr Well if it must be synced it must be synced. I understand that. The simplest way to do it would be to use setInterval and const [lit, setLit] = useState(false) and toggle the state, and the state toggles the class <div className={classnames({'foo_is-lit': isLit})}
Mar 6, 2021 10:00
Thousands of developers use the library in thousands of projects, it is well established, and well designed. So maybe you imagine some need here that is not really a pressing need, and can be solved with some cleanup of css rules. But anyhow, in the end its your project and your judgment that counts.
Mar 6, 2021 09:55
* Mutually exclusive css classes: I don't think you need it. Most of it can be covered by the order of css rules in your css files, or by specifity, and ultimately: `classnames` allows the on/off switching of classes controled by property values or other conditions and I have not seen any parts of your current project where that would not be sufficient: So with classname you can do something like:
`<div classname={classnames({ 'foo_is-active': someProp, 'foo_is-deactivated': !someProp })} />`
Mar 6, 2021 09:49
so I opted for the simpler variety here.
Mar 6, 2021 09:48
* I saw that you added the icon class to all your icons. But I somehow think the added overhead with your wrapper is not worth it. And there is probably some way of configuring @svgr/webpack to automatically add that class, although I do not know. Anyhow, I have learned during my work so far, that simplicity is a target worth aiming for (as long as it not compromises correctness)
Mar 6, 2021 09:45
@bzrr Your points are valid, I admit. And I was aware of each of them when I decided to change your implementation and replace it with something else. I will let you in on my thoughts. Ultimately the decision lies in your hands.
So here my reasoning:
* I think the clock drift will not be noticable for awhile. I don't know how long it takes, but assuming it needs more than 30 minutes of continuous blinking to get noticable I think it is worth it to get rid of the need to switch css classes on and off with code.
Mar 5, 2021 20:58
and I created a HTMLAttributFunctionalComponent type that can be used for all the components
Mar 5, 2021 20:58
and I used pure CSS for the blinking animation
Mar 5, 2021 20:57
You are welcome. Good night. The current master branch in my forked repo is runnable. You could clone it and run it if you want. I added the 'classnames' dependency and the corresponding type definitions. I have not replaced useClassname everywhere. I plan to continue tomorrow
Mar 5, 2021 20:46
And btw: your source code is really quite nice. Can be simplified alot, but the code itself is really quite clean and well structured.
Mar 5, 2021 20:45
I would like to cpontinue refactoring the forked code because I'm curious where it leads me. And also I quite like working with react code.
Mar 5, 2021 20:44
Hi. My local time is 21:44 and I'm preparing to go to bed