Live data from Hacker News

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

typeofnan.dev

121–130 of 444 posts

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

#121
post #41

Earlier quoted context omitted.

I guess this is just a limitation of JS the language showing itself. Other languages have actual aspect-oriented support where before/after/around methods are very clear name-wise and semantics-wise (if not always so clear without tooling support what happens if you come across a 'mount()' call). Maybe it's time for a new JS framework! /s

Which languages in common industry use in 2022 have language-integrated aspect-oriented programming support?

Fair point. I hinted with the idea of a new framework that you may be able to bolt something acceptable on top of JS (I'm sure it's been done already in the past with some framework) especially if you just want the before/after/around advice features of AOP without other stuff. Or perhaps go into custom syntax transpiled to JS/TS-then-JS since no one seems to mind heavy build processes these days. For the most common industry use, I'd have to say it's still Java's Spring AOP/AspectJ. Maybe it's not language-integrated, but it's pretty close.

For an uncommon use example of what could be possible:

    (defmethod react.component:mount :after ((self counter)) ...) ; instead of componentDidMount
    (defmethod react.component:update :around ((self counter)) ...) ; instead of shouldComponentUpdate
    (defmethod react.component:unmount :before ((self counter)) ...) ; instead of componentWillUnmount
    ; (the react.component namespace qualifier could be whatever else and not necessarily typed out)
However closely you integrate it with the language, having that machinery generally available seems better for naming and for providing new lifecycle functionality, without everyone having to reinvent the wheel and provide it in different incompatible ways. But it's clearly not a big issue.

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

#122
post #120
post #96

Earlier quoted context omitted.

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching. React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't. you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the…

I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. A…

> View = F(data)

That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

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

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

Maybe the name is trying to communicate it happens after the component mounted instead of just before

`on_mount_complete` sounds more professional

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

#124

This is the same code in Svelte.js # Counter.svelte let count= 0 setInterval(() => { count += 1 }, 1000) The count is: {count}

What does a reusable (ie import from another file) `useAutoCounter` look like in Svelte?

Probably the equivalent would be a custom store, something like this:

  
    import { writable } from "svelte/store";
  
    function autoCounter(interval, initialValue = 0) {
      let { subscribe, update } = writable(initialValue);
      setInterval(() => update((n) => n + 1), interval);
      return { subscribe }
    }
  
    let counter = autoCounter(1000);
  
  
  The count is: {$counter}

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

#125

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

Hooks triggered my code smell detector so bad that I didn't even bother finishing the tutorial.

That said, I still preferred React.createClass so I guess I'm somewhat off the beaten path when it comes to React.

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

#126
post #120

Earlier quoted context omitted.

I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. A…

> View = F(data) That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

Consider following scenario:

User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use.

Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

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

#127

> That’s a lot of code to write for an auto-incrementing counter. Is 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.

> Terseness is not always a virtue.

This is a subjective thing, right? Personally, I hate boilerplate: either it's a distraction because it's boring and superfluous, or worse it's long and it's wrong. Regardless, it adds to the cognitive load when maintaining code.

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

#128
As part of my annual routine, I'm exploring the "latest and greatest" JavaScript UI library. Solid.js's performance seemed compelling. 15 minutes into documentation and this is what I encountered. Can you guess which one of the ChildComponent* updates when the text input on the parent component is updated, and the props passed to the child?

  export default function ParentComponent() {
    const [value, setValue] = createSignal("");
      return (
         
            
             setValue(e.currentTarget.value)} /> 
        
    );
  }
  
  const ChildComponent1 = ({ props }) => {props};
  const ChildComponent2 = (props) => {
    const value = props.value || "default";
    return {value};
  };
  const ChildComponent3 = (props) => {
    return {props.value || "default"};
  };
  const ChildComponent4 = (props) => {
    const value = () => props.value || "default";
    return {value()};
  };
  const ChildComponent5 = (props) => {
    const value = createMemo(() => props.value || "default");
    return {value()};
  };
  const ChildComponent6 = (props) => {
    props = mergeProps({ value: "default" }, props);
    return {props.value};
  };
  const ChildComponent7 = (props) => {
    const { value: valueProp } = props;
    const value = createMemo(() => valueProp || "default");
    return {value()};
  };
  const ChildComponent8 = (props) => {
    const valueProp = props.value;
    const value = createMemo(() => valueProp || "default");
    return {value()};
  };
The answer is 3, 4, 5, 6. My takeaway is this: there are multiple ways of doing it right, but also a handful of gotchas. The only way to be safe is to keep the mental model of these partitions while you develop, test, debug, and code review. As a code reviewer, you can easily accept the wrong code. For now, I remain skeptical of Solid.js as solving the complexity woes of Reactive programming. I'm not sure React.js is better.

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

#129
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…

>Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework…

Solid has done some branding around performance but the promotion is shifting to be more balanced, as Solid really isn't about performance. Solid's biggest priority has been to give the best DX for building performant applications that stay maintainable at scale and after years of work on the same project. Solid might seem harder than Svelte or Vue to get started with (although this is arguable IMO) but due to it's simplicity I think that it's much easier to master and understand what actually is going on.

Compare this to Svelte which has the goal of creating the perfect high level abstraction so that you never need to understand how things work and was originally created for smaller one off projects with much smaller complexity and no maintenance burden.

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

#130

Earlier quoted context omitted.

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times stil…

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing numbe…

hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code)

If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d.... It was very common for developers to make things that would repeatedly rerender when other parts of their app updated. Hooks make that far less likely to happen.

That said, I agree that a getDerivedStateFromProps method is more readable and much clearer than useEffect(()=>{ // stuff }, [big, list, of, props]);

Post reply on HN