241–250 of 444 posts
> 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.
Earlier quoted context omitted.
> In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of…
What JS framework would you choose to work with big datasets like, e.g. a data grid with half a million rows that should have a "filter as you type" functionality?
My specific use case is a React application, and I have found it easier to implement a dedicated listener system, than try to fit things into component states.
Earlier quoted context omitted.
Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse er…
> Because you sometimes want to filter, sort or project your data. The idea that this type of thing should be happening anywhere near the view rendering loop is the exact reason I've not had a great time picking up React codebases. By the time you're rendering data into markup, the data should be in the exact state you need it. No further filtering or data mangling or sorting. That type of data manipulation should ha…
It’s nice to have a concept “ground truth” in data and props and then computeds that sort of tie it all together.
I love the new ergonomics (hooks, useEffect, redux tools) but I definitely hit the exact issue OP mentions almost immediately.
I don’t feel that the solution react provides is too out there, but agree it could be better. The react ecosystem still makes it worth the one or two “could be betters” for me.
Earlier quoted context omitted.
Weird. I'm not British by I say "used xyz in anger" because I read lots of other programmers saying it. Had no idea it was regional, thought it was hacker lingo like "grok".
Australian living in England as a dev for 5 years. Never heard of "used in anger" in any context. Weird.
This article perfectly captures the essence of why I no longer work in web development. Never again!
I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…
> Solid takes these problems and just vanishes them. UI state knows what its dependencies are automatically and only updates when they change – even in a sub-component level! I haven't looked at Solid but I've used MobX extensively, and this sounds a whole lot like it. It integrates well with React, so you might give it a look if you've got an existing React codebase.
I love solidjs, but the similarities to React are the hardest part for me. The semantics are so similar, but the mechanics are the polar opposite. In react, everything is a function and all your code runs on every render unless you specifically tell it not to. This really encourages a certain style of writing code and provides a lot of guarantees about safety and scope. Solid is literally the polar opposite, your cod…
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…
>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! Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because…
Earlier quoted context omitted.
Thats interesting. So in your 2nd example, am I right in saying the variables 'apple' and 'slicedApple' are react JSX that you are ultimatly passing through to to render on the screen? If so, yes, that is fairly intuitive.
'apple' and 'slicedApple' would more likely be strings / objects / arrays in the real world. Maybe this still woefully contrived version is clearer? function FacebookComment({ commentId }) { const comment = useGetComment(commentId); const likes = useGetLikes(comment); return ( {comment.text} {likes.length} likes ); } I don't think deal with more braces right now to bring the alternative into existence unfortunately