Comments (5)
What would be the benefit of doing this? The way the cookie is stored at this moment does not require serialization or parsing.
More importantly, you actually want the darkModeOn
to be readable on the server side. This is especially important if you are using backend frameworks like Laravel/Django/Rails where the view function generates and returns the template. On those types of stacks, the saved dark-mode preference can be set server side without JS (see: #28 (comment))
from halfmoon.
From a quick research GDPR don't applies only to cookies but localStorage too. For me the best option to avoid storing info about the user is not storing any information at all until the user interacts with the page, which I already suggested here. If the user interacts with the page wanting to change their dark mode preference then it's safe to assume that the user gave consent to store this information, which, from what I understand, is not a issue with GDPR.
Using a cookie and server side rendering it's possible to avoid the unwanted flash of light mode, but there are many solutions. One that avoids this issue without using real server side rendering is using service workers to emulate server side rendering (demo) which is, of course, too hard to implement. I think that the best option for the framework is providing a simple implementation that will solve this issue for most users and documenting what the optional JS library does so anyone can implement their own toggleDarkMode()
function using localStorage, or Service Workers, or React, or Vue, or Choo... whatever.
from halfmoon.
I understand the point made in #28.
But I could see future users of this framework who do not want their users to need to use cookies. Especially in times of GDPR.
It could of course be argued that they are essential cookies.
Maybe the option to choose between cookie and localStorage could be a possibility.
With serialization/parsing I meant:
Lines 47 to 75 in 37d569f
from halfmoon.
After thinking about this issue quite a bit, I think @qgustavor has the right idea. If GDPR applies to both cookies and localStorage, then there doesn't seem to be any advantage using localStorage. This could be made into a choice for the user, that is, pass in a parameter to select whether you want to save it in a cookie or in localStorage, but that seems like extra complexity without any real benefit.
I especially agree with the point that the framework should provide a simple implementation (ideally one that works for 95% of users in a way that they don't even have to think about it). The rest will have to override the method for more complex use cases. For example, I had to override the toggleDarkMode()
method for the pages with iFrames in them on the documentation website.
Moreover, I would say the cookie definitely falls under essential. So, if I push what @qgustavor suggested in the next update (that is, cookie is not set until the user interacts with the page), there should be no issue going forward.
from halfmoon.
The whole dark mode preference implementation has been overhauled in v1.1.0. Please refer to this page of the docs: https://www.gethalfmoon.com/docs/core-javascript-library/
Basically, what I wrote in my previous comment has been implemented in the framework. I will go ahead and close this issue. You can re-open it if you think the issue is still not resolved, or open another issue.
from halfmoon.
Related Issues (20)
- Modal close event HOT 3
- Select does not work properly in mobile
- set color mode instead of toggle js HOT 2
- [Feature request] Put label before switch
- Sidebar, darkmode and modals are not automatically toggled as expected. HOT 5
- halfmoon doesn't support rtl? HOT 2
- require problem while using with sveltekit. HOT 1
- this.stickyAlerts is undefined HOT 1
- Will the project continue? HOT 2
- Text centering inside buttons
- Default sidebar with small screen results in offscreen content HOT 2
- Halfmoon documentation isn't available anymore HOT 37
- is this project dead? HOT 27
- Version update messed up page layout completely HOT 3
- Provide CSS only alternatives using Dialog and Popover API.
- CSS only form validation HOT 1
- Website is down HOT 1
- Typo in dropdowns page code snippet
- input type = date, just use this that way?
- Docs website for v1.x.x is down HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from halfmoon.