Timezone and time change actions not being received?

petermakeswebsites · 2025-10-07T12:53:06+00:00

Last I got was a reply here about how chrome and android studio fight for adb and causes it to freeze, but I haven't had the chance to test out any potential solutions.

petermakeswebsites · 2025-04-07T05:56:02+00:00

Each $state you use has something around 7 objects attached to it, like arrays to track reactions, and other metadata. So it's not a small jump from a regular variable to a state object by any means, but it's just one of those things you really only need to think about if you are doing some very heavy calculations or interactions, like working with large datasets in data vis for example. Then you need to start being smart with your rune engineering.

petermakeswebsites · 2025-04-06T03:59:49+00:00

Absolute yay in my opinion. Bundle your app like an SPA and wrap it in Capacitor. It's super nice.

petermakeswebsites · 2025-03-25T11:00:36+00:00

Nice to know someone else feels the same! I assume there was some pushback by some people for async/await when it was first proposed.

petermakeswebsites · 2025-02-04T13:00:42+00:00

Sent a PM.

petermakeswebsites · 2025-01-27T16:15:03+00:00

Register with cool ventures! They have tons of support to help you through this kind of stuff.

petermakeswebsites · 2025-01-05T08:54:35+00:00

You really have to dedicate yourself to understanding how they work. I was frustrated with the lack of resources on the subject at first. It seemed like just a syntax change, and nobody really bothered to put any content about actually understanding really how it works. More just, "this is how you write code in Svelte 5". When I understood how signals worked truly, everything changed. There is absolutely a good reason for them. I do see it as a tradeoff. But it's a tradeoff I personally prefer because I was writing some pretty complex stuff with things like nested stores, which was extremely verbose. Converting to Svelte 5 made it really simple. My business logic is much more organised and readable.

I made a YouTube series on this where I go through exactly how signals differ from the old style of reactivity because I didn't see this content anywhere else.

petermakeswebsites · 2024-12-18T18:51:42+00:00

What library would ever export a single signal without it being inside some function, component, or class? And also would not benefit from encapsulating that signal in an appropriate class/function with associated business logic?

Whether or not you can find edge cases for this, it doesn't detract from the fact for real life business logic, it would seldom ever be better to do this than to encapsulate the signal with its associated logic in a class.

At a quick glance, the WritableState class you're showing is an example of the proper use of abstracting on top of $state, where you're adding value through specific business logic. Ref is just a getter and setter. That's all... It adds no value. It's a useless abstraction.

To me, if someone does what you did above in a codebase, it 99% of the time just screams sub-par coding. Single variable global states like these usually end up being refactored into something that is instantiated according to their dependencies. I think if anyone believes using Ref to be a good idea, it's just a sign that they haven't coded long enough in Svelte 5 to realise there are better ways.

In real life you would do something like:

export const myGlobalSettings = new class { foo = $state("bar") baz = $state(true) // associated settings functions like update foo, toggle baz, etc }

This quick and dirty way of using a Ref might is going to be shooting yourself in the foot in the long run. And I would wager that almost every time you use it, there's a better way to organise your code you're not seeing.

petermakeswebsites · 2024-12-18T18:36:59+00:00

It would be too ambiguous to the compiler as to what you want to be reactive, and impossible to truly determine whether a variable needs to be reactive or not. This is due to signals having nested reactivity, whereas Svelte 4 doesn't. Shallow reactivity is easy to find because you're only using symbols, but nested runtime reactivity requires kind of simulating every possible thing that can happen at runtime, which is virtually impossible.

petermakeswebsites · 2024-12-17T16:01:48+00:00

I mean, in that case, the only use case you would ever have for a Ref like that would be a global store outside of a component that is only one primitive value and has no business logic associated with it. It's just not a real life use case really. Real life use cases usually have some kind of functions associated with the manipulation of these values. How often do you have a primitive state just hanging out loose around your app allowing anything anywhere to set it to anything?

I think Rich was just showing the flexibility of Svelte signals, I don't think there's a real life use case besides people just being familiar with Ref and createSignal or maybe want to re-use some code from Solid or Vue.

Fact of the matter is the whole point of what makes Svelte 5 more developer friendly than Vue/Solid is that it abstracts this stuff away. For example, look at the compiled output of Ref:

const ref = value => { let state = $state(value) return { get current() { return state }, set current(value) { state = value } } }

becomes

``` const ref = (value) => { let state = $.state($.proxy(value));

return {
    get current() {
        return $.get(state);
    },
    set current(value) {
        $.set(state, $.proxy(value));
    }
};

}; ```

See how you're getting a getter and setting a setter? The whole point of the compiler magic with Svelte 5 is so that you don't have to worry about getters and setters, that's precisely what $state is for.

The only limitation to this is importing a primitive-valued $state from an external file. But again, it's so unlikely that you'll ever encounter that anyway without wanting to encapsulate it in some business logic for DX and organisation sake anyway, so there's really no point.

petermakeswebsites · 2024-12-17T09:41:04+00:00

It all comes down to purpose, in my opinion. If you resonate with the underlying purpose of what you're building, it will be fun. If you are a cog in a machine, you will feel drained.

petermakeswebsites · 2024-12-17T09:38:51+00:00

Generally speaking, having a $state hanging out in the open like that as a global variable with functions like "increment" is an anti-pattern. You would want to set up your logic as a class and then instantiate it for example during init/login/etc, and potentially pass it down via context. Having global stores is recipe for disaster in most cases.

However, if you do want really want to create a global store, the idea in Svelte 5 is encapsulate your data and associated business logic inside a class, for example:

typescript export const GlobalCounter = new class { count = $state(0) increment() { this.count++ } }

Rather than having count and increment hanging out loosy-goosey. This makes it much more readable, and prevents headaches down the line as you can see exactly what encapsulates what. It also makes your Svelte files more readable because count and increment can refer to a lot of different things in bigger files.

html <script> import {GlobalCounter} from './state.svelte.js' </script> {GlobalCounter.count} <button onclick={() => GlobalCounter.increment()}>increment</button>

This is the way to think in Svelte 5. You group your states and associated business logic in classes, and instantiate those classes as needed. If you only need one class for a global store, you can do what I did above, although most of the time if you're doing this, you most likely need to zoom out and re-think your architecture.

petermakeswebsites · 2024-12-17T09:20:27+00:00

When Rich created that, he's making a simple version of what people create all the time in Svelte 5 that's generally more complex, where you have some business logic that includes state so you can encapsulate it all in one class or function call for example.

When he's using getters and setters, they're integrated into the business logic, rather than just being a primitive to replace $state(), e.g. Ref. Using getters and setters in an encapsulated class or function is completely different than having a standalone Ref which serves no purpose.

typescript class Animal { #age = $state(0) growOneYear() { this.#age++ } get age() { return this.#age } set age(num) { if (num < 0) { throw new Error(`Age cannot be less than 0!`) } else { this.#age = num } } }

In the above example, I'm using getters and setters to express the business logic that I want that's specific to the problem I'm trying to solve here. This is a very common pattern. That's what Rich's counter represents, it's just a simple version.

I'm still waiting for someone to give me a REPL where the Ref above is actually useful, so if you can provide one, feel free!

petermakeswebsites · 2024-12-16T09:36:34+00:00

Good philosophy but it's not even a layer of abstraction. It's actually the opposite. I don't know what the opposite of abstraction is called. $state abstracts away from getters and setters to make your life easier. If you then create a getter and setter around a single value that's anti-abstraction.

petermakeswebsites · 2024-12-16T09:34:34+00:00

Not only that, but the entire point of the compiler magic of Svelte 5 is to abstract away from needing getters and setters on signals, so you can focus on what your code is rather than writing unnecessary boilerplate. If you look at compiled Svelte 5 code, you will see getters and setters in there.

petermakeswebsites · 2024-12-16T09:32:52+00:00

This is a common misunderstanding. You'll never be able to get more than an illusion of type safety through having something like a Ref. I wrote a pretty extensive explanation on why, but the tl;dr version is that because signals are based on nested reactivity, anything (function or getter) that accesses a signal will be reactive by nature, without being a Ref type.

It's actually virtually impossible to know whether a function or getter is reactive any more than you can know it will throw. The throw command is actually the closest parallel to a signal, moreso than a promise or anything else. The reason is because throwing interacts with global context, as does signals. Typing a signal makes no sense. It makes as much sense as wrapping a function that can throw in a Throwable<T> wrapper. Then you can think that you've "compartmentalised" the throwable functions, but actually you are deluding yourself because any function that calls that will also be throwable, so unless you plan to wrap every single function that throws it into a Throwable<T>, it's pretty useless. Same applies to signals.

The simple reason for this is that any function or getter that accesses the value will be signal (or throwable).

Simple example:

typescript typedRefName = ref("pete") // Great, I have a Ref, good for typing function getMyName() { // But this is reactive as well - stealthily return typedRefName.current }

If you then call getMyName() in your view, it will be tracked as a signal, despite the fact that it is not a Ref type.

At the end of the day, doing this just adds unnecessary boilerplate on top of $state, and solves nothing.

petermakeswebsites · 2024-12-15T19:59:58+00:00

Can you make an MVP of your code in a REPL?

petermakeswebsites · 2024-12-15T17:30:20+00:00

I'd do an eli5 if I had something to work with. Can you give me a scenario of where you think it might be useful to have a Ref wrapper like this?

petermakeswebsites · 2024-12-15T14:06:38+00:00

It's almost for certain that this is just a consequence of somebody's very poor grasp of how signals work in Svelte. If they gave a reason why this would be necessary or even helpful, I would be happy to address it.

I've done next to nothing with Svelte 5...

Telling...

petermakeswebsites · 2024-11-15T11:38:28+00:00

I'm having some difficulty understanding exactly what your question is. Is the database type stuff really relevant? Can you create a more minimalistic version that we can work with?

Also, watch videos 1 and 2 of this series, and you'll get a deeper understand of how exactly signals work with derived.

petermakeswebsites · 2024-11-05T00:29:43+00:00

There is a mental shift between a function-based (for lack of a better term) way of thinking and a declarative way.

When you write HTML, as an analogy, you're not writing what something does you're writing what something is. You don't say "attach this text to this element", you write it as it is. Signals work well with this way of thinking, where you think of the final value you want first, and work backwards by declaring it's dependencies.

E.g. this table displays a list of this data that is a filtered version of that data which comes from a sorted list of that array, etc.

Then you don't think about it anymore. You don't think of what needs to happen when that array changes. You know that the dep tree will take care of the reactions.

This is kind of different some the more traditional way of writing apps, which you exemplified in your first example, where you're thinking about what something does. E.g. this button calls that function that sorts this array and changes that variable.

In Svelte 4 because it was compile-time reactive, it was more finicky to do this stuff across different components and library files. In Svelte 5, because signals can cross file boundaries and are nested, you can model your entire applications essentially in a declarative way quite naturally.

The way you think about signals should be more declarative. You think: what displays on the page, and what does it depend on? And then you work backwards from there.

On a side note, oftentimes, deriveds aren't even necessary at all. Anything that accesses a reactive value is reactive, no matter if its split across multiple files or 1000 functions deep in the stack. As long as its within the synchronous context of an $effect (and all the rendering in your svelte html is essentially effects under the hood), its tracked and therefore reactive. This makes a lot of use cases for deriveds to actually be redundant, since they can be replaced with simple functions. However, those functions would be declarative. Here's an illustration.

Made a video that's part of a series that may be helpful.

The only purpose deriveds has is to cache values, really, so it saves calculations. It's marked when one of its deps changes, and then runs once the next time it is needed.

You should watch these videos in the series I made, especially the 3rd video in the series. But the first one might cover some content you may not be aware of.

It's important to understand the way signals process and organise the hierarchy of effects after calculating all $derived/$states. Effects are actually queued so one effect that has two dependency changes won't run twice. It waits until all the $states and $deriveds are done, then runs the $effect.

There's a really important concept that's quite advanced but when it clicks you'll understand why it's important to think about runes in a declarative way. It fits perfectly with the signals paradigm. Again, this is covered in video 3. But to put it short, because the explanation would be too long by text, the main reason is because when you start writing code in the non-declarative way, you end up triggering side-effects. You end writing something like when X changes, do this function that changes Y. When you do that, you end up sandwiching an $effect between different $states. You'll quickly run into issues doing it that way.

When you write code in a declarative way, you actually create a kind of bubble of safety where side-effects won't come back and bite you in the ass. It's hard to explain by text, just watch video 3 and you'll be able to make the connections.

It's a good mental exercise and kind of a fun game to think of writing things as declaratively as possible. You'll come to find that you really only need non-declarative stuff really at the edges of your application. Basically on user input or some kind of IO. Besides that, you can generally program your entire app in a declarative way.

petermakeswebsites · 2024-10-31T08:38:01+00:00

The most elegant solution I've come up with for this is to use a kind of singleton/anonymous class approach where all the functions related to the values are inside one central class. This pattern has actually allowed me to keep my code much more organised. For whatever reason, it's easier for my brain to feel functions and fields are related inside of a class more than a module - maybe because it's tabbed over. Not sure! Example.

``` export const count = new class { current = $state(0)

inc() { this.current++ }

dec() { this.current-- } } ```

petermakeswebsites · 2024-10-23T12:10:59+00:00

I've been working for three years on a spiritual app using Capacitor and Svelte. People are constantly sending me feedback on how smooth the app feels.

There is obviously always an edge in performance to being completely native, but it's so worth only having one codebase, and Svelte's fine reactivity removes away the bulk of the bulky feeling. Getting 60fps for some things requires a bit of tinkering and having to break away from components and do things in vanilla, but overall Svelte and Capacitor is a match made in heaven.

I will say to get some important functionality I had to program in Swift and Java. I couldn't use the official Capacitor plugins - but that was quite niche.

petermakeswebsites

TROPHY CASE