Comments (14)
This is just how things are logged. it will probably just need to upgrade the toString method too.
However since this is blocking an upgrade for you go ahead and use it because the values are there :)
EDIT: apparently the console
api is not standardized and there's no assurance that changing toString
will customize how it prints an object.
from svelte.
However since this is blocking an upgrade for you go ahead and use it because the values are there :) ...
see this repl as well.
As the docs mention, they should behave exactly the same, except this one is reactive. So I still beleive this is not intented.
<script>
import {Set} from "svelte/reactivity";
const data = ["1", "2", "3", "4"];
const nativeSet = new window.Set(data);
const reactiveSet = new Set(data);
// 4 elements get logged cause 4 elements in here
nativeSet.forEach((a)=>console.log("n",a));
// nothing gets logged cause nothing in here
reactiveSet.forEach((a)=>console.log("r", a)); // expected to log "r 1 ... 4"
// or if the console.log is not correct as @paoloricciuti says we can test it
reactiveSet.forEach((a)=>console.log("something")); // expected to log "something" 4 times
</script>
I've commented what I expect from the console logs, don't you agree they are logical? (this the code from the REPL I've linked)
from svelte.
This is caused by #11200. The following are broken, I believe: forEach
, isDisjointFrom
, isSubsetOf
, isSupersetOf
, difference
, intersection
, symmetricDifference
, and union
.
from svelte.
However since this is blocking an upgrade for you go ahead and use it because the values are there :) ...
see this repl as well.
As the docs mention, they should behave exactly the same, except this one is reactive. So I still beleive this is not intented.
<script> import {Set} from "svelte/reactivity"; const data = ["1", "2", "3", "4"]; const nativeSet = new window.Set(data); const reactiveSet = new Set(data); // 4 elements get logged cause 4 elements in here nativeSet.forEach((a)=>console.log("n",a)); // nothing gets logged cause nothing in here reactiveSet.forEach((a)=>console.log("r", a)); // expected to log "r 1 ... 4" // or if the console.log is not correct as @paoloricciuti says we can test it reactiveSet.forEach((a)=>console.log("something")); // expected to log "something" 4 times </script>I've commented what I expect from the console logs, don't you agree they are logical? (this the code from the REPL I've linked)
As @harrisi was saying this is a different problem from what you showcased in your first repl. I'll see if I can find a fix tomorrow (I don't know if I'll have time tho so if someone else wants to work on this go ahead)
from svelte.
The fix is to revert #11200 or implement all the methods that are currently implemented by calling Set
methods applied to the ReactiveSet
. Since that change removes super
calls, the parent Set
doesn't have any data, and those methods are being called on an empty Set
(or Map
).
Or, don't extend Set
and have ReactiveSet
have a Set
rather than be a Set
. This will break the next time a method is added to Set
(or Map
or Date
or URL
or URLSearchParams
) as well.
from svelte.
The fix is to revert #11200 or implement all the methods that are currently implemented by calling
Set
methods applied to theReactiveSet
. Since that change removessuper
calls, the parentSet
doesn't have any data, and those methods are being called on an emptySet
(orMap
).Or, don't extend
Set
and haveReactiveSet
have aSet
rather than be aSet
. This will break the next time a method is added toSet
(orMap
orDate
orURL
orURLSearchParams
) as well.
Yeah i also commented on the PR. Personally i would revert #11200 ...you could replicate those methods but then there's more work to maintain those classes for a small memory gain.
from svelte.
It's not only more work, it's not forward-compatible.
from svelte.
@harrisi what about wrapping the native set
, url
and etc in a proxy instead?
from svelte.
@harrisi what about wrapping the native
set
,url
and etc in a proxy instead?
You would still need to call those methods on an actual set instance or JS will throw.
from svelte.
and also, should it be forward compatible? What if standard adds a new method that mutates the original set in someway, it shouldn't be available in ReactiveSet
right away, it might require some modifications.
from svelte.
and also, should it be forward compatible? What if standard adds a new method that mutates the original set in someway, it shouldn't be available in
ReactiveSet
right away, it might require some modifications.
The current implementation would still let you call whatever new Set
methods may be added but wouldn't do anything, or do something weird. One alternative would be to define a ReactiveSet
without extending Set
, so it won't be a Set
, but look like it. It would still work in many situations, except instanceof Set
would return false, and types get all weird.
This discussion is pretty spread out across different places, and really isn't specific to this issue, though.
from svelte.
and also, should it be forward compatible? What if standard adds a new method that mutates the original set in someway, it shouldn't be available in
ReactiveSet
right away, it might require some modifications.The current implementation would still let you call whatever new
Set
methods may be added but wouldn't do anything, or do something weird. One alternative would be to define aReactiveSet
without extendingSet
, so it won't be aSet
, but look like it. It would still work in many situations, exceptinstanceof Set
would return false, and types get all weird.This discussion is pretty spread out across different places, and really isn't specific to this issue, though.
But what if the "new methods" added to Set
requires overriding the method to make it reactive? for instance lets say the add
methods will be introduced tomorrow. You will use it assuming it will be reactive because it's comming from "svelte/reactivity" and it is a reactive Set
. Current implementation allows you to do so but might introduce bugs and unexpected behaviour. My point is:
- if
ReactiveSet
inherits fromSet
it will be forward-compatible by newest JS standards but might break what svelte users assume it does - if
ReactiveSet
doesn't inherit fromSet
but holds an internalSet
instead it might not be up to date with what js standard does, but will be compatible with sveltes point of view.
I don't know which one is better.
from svelte.
See #11287 for a potential solution
from svelte.
This works now
from svelte.
Related Issues (20)
- Svelte 5: Class fields aren't reactive HOT 14
- Svelte 5: svelte-ignore a11y_autofocus is ignored HOT 1
- Svelte.dev suggestion: version switcher HOT 1
- Add error when a {#snippet} hide a props HOT 2
- Svelte 5: Confusing error "Error: get is not a function or its return value is not iterable" HOT 4
- Critial: static analyze some.svelte.ts HOT 3
- Hooks to manipulate the Svelte compiler HOT 5
- Svelte 5: svelte-ignore unknown/legacy code warnings are misplaced
- `state_referenced_locally` warning should skip type declarations
- Transitions not working properly in Svelte 5. HOT 2
- Svelte 5: `<select>`/`<option>` elements get incorrect/inconsistent values when applying `undefined` with spread or reactive value
- playground: console formatting isn't applied HOT 2
- Svelte 5: Setting the `loading` property for `img` in the `$effect` rune does not work HOT 2
- Svelte 5: Throw an error when importing svelte/internal/* HOT 3
- Binding scrollY to `svelte:window` causes implicit scrolling to the top of the page HOT 6
- Object literal may only specify known properties, and '"on:accept"' does not exist in type 'Omit<HTMLInputAttributes, keyof HTMLAttributes<any>> & HTMLAttributes<any>'. HOT 3
- Svelte 5 playground is freezing HOT 2
- Binding to store values not working correctly in Svelte 5 HOT 4
- Remove `indeterminate` from `HTMLInputAttributes` type HOT 1
- Default values for array-like props breaks rendering 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 svelte.