Live data from Hacker News

Solid.js feels like what I always wanted React to be

typeofnan.dev

71–80 of 444 posts

Re: Solid.js feels like what I always wanted React to be

#71
post #58
post #49

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…

Interesting. I guess it just boils down to different preferences.

Re: Solid.js feels like what I always wanted React to be

#73
post #16

New 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?

JSX doesn't have loops. When using React, you use regular not-React-specific Javascript tools to do loops and create lists of React elements.

Re: Solid.js feels like what I always wanted React to be

#74
post #42

Earlier 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…

> The mechanism that enables code reusability is through composing components

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

#76
post #15

Every 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() { .... }

componentIsNotThatBotheredButStarSighStarIfIMust() { ... }

Re: Solid.js feels like what I always wanted React to be

#77
This looks a lot like my current favorite state framework (which yes is done by Facebook people), Recoil - https://recoiljs.org/

Your 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

#78
post #44

I 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 :)

Me too. TypeScript is a disaster.

Re: Solid.js feels like what I always wanted React to be

#79
post #58
post #49

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…

That would be true if all a react component was dom output. But since it has side effects (rest calls, mutating state, effects), rerunning everything is the wrong thing to do in almost all instances.

Re: Solid.js feels like what I always wanted React to be

#80
post #10

I 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 think for progress you need to look outside the js world. Fundamentally, people keep repeating the same mistakes there.

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.

Post reply on HN