Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary beca…
> Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary be…
Solid.js feels like what I always wanted React to be
71–80 of 444 posts
Re: Solid.js feels like what I always wanted React to be
#72Re: Solid.js feels like what I always wanted React to be
#73New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…
> we get a construct like that reinvents a concept that's already in the language Isn't this optional? Can't Solid use regular JSX loops?
Re: Solid.js feels like what I always wanted React to be
#74Earlier quoted context omitted.
Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequent…
> Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way. You’re using React. The mechanism that enables code reusability is through composing components. There’s nothing wrong with class components even for the most complex logic. The only downside is the community has moved on and mostly adopted hooks and functiona…
If you think that this:
return (
{({ apple }) => (
{({ sliced: slicedApple } => (
)
}
)}
);
is more desirable than this: const apple = useApple();
const slicedApple = useSlicer(apple);
return ;
Then go for it I guess.Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate functionality steps to interact with the parent component in a non-trivial way, ..
Needless to say, I have written such render-prop and "renderless" components in the past, and I see very little upside compared to hooks.
Re: Solid.js feels like what I always wanted React to be
#75Is it though?
I mean I happily write more code for a single-page Vue component for something like this.
Terseness is not always a virtue.
Re: Solid.js feels like what I always wanted React to be
#76Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }
Re: Solid.js feels like what I always wanted React to be
#77Your naming however reminds me of the RxJS and general reactive programming paradigm I've always pined after... some combination of the two would be my UI state management holy grail.
Re: Solid.js feels like what I always wanted React to be
#78I hate the whole javascript ecosystem to the core. Hey I just finished my progressive web app with these 10 cool react components I found on NPM which fit surprisingly well into our startup’s cloud-native Vue interface. I tried to put the code up on GitHub but it wouldn’t let me upload a 10gb repository (and that was without our proprietary fork of mysql :)
Re: Solid.js feels like what I always wanted React to be
#79Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary beca…
> Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary be…
Re: Solid.js feels like what I always wanted React to be
#80I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…
I'm having a lot of fun lately using Kotlin-js for example. We use the Fritz2 framework, koin for dependency injection (popular on Android as well for good reasons), and fritz2 relies on kotlin's co-routines and StateFlow for state management. It makes for a surprisingly concise code base. For example, the counter example from the article with that would look something like this:
class CounterStore : RootStore(0) {
val koinCtx by lazy { GlobalContext.get() }
// handler that you can bind events to or invoke directly like below
val inc = handle { old -> old + 1 }
init {
// launch co-routine to keep on incrementing the counter
GlobalScope.launch {
while (true) {
inc()
delay(1000)
}
}
}
}
val koinCtx by lazy { GlobalContext.get() }
fun RenderContext.counterComponent() {
val counter by koinCtx.inject()
h1 { +"A Counter" }
// react to changes in the counter
counter.data.render { currentCount ->
p {
+"Current count: $currentCount"
}
}
pushButton {
icon { arrowUp }
events {
clicks handledBy counter.inc
}
}
}
fun main() {
startKoin {
modules(
module {
single {
CounterStore()
}
})
}
render("#target") {
counterComponent()
}
}
There's a lot going on here that I can't explain here. But having co-routines means having a proper reactive framework that you use to react to events and update stores, which is where you keep your state. counter.data is a so-called StateFlow; the render function maps updates in that flow to the dom. In the example I have both a button and a co-routine updating the store via a handler lambda function.Using koin here, just means keeping glue code out of places where it doesn't belong. It's technically optional but makes a lot of sense in larger applications. Because components are extension functions on RenderContext, I use a global variable to get to the koin context. That allows me to inject my dependencies into components with a minimum of fuss. Where Fritz2 gets fun is with more complex state using data classes, lenses, validators, routers and a few other things. And they also take care of styled components and they even have a nice component framework that you can use. Not for everyone and there's a bit of overhead in terms of download size. But great if that less of a concern.