21 ms·
VanJS – A no-JSX framework based on vanilla JavaScript
- iamsaitam 3y agoWhy do people dislike JSX? For me the lack of JSX is a negative point. Why would I want to write nested functions everywhere? JSX is HTML on steroids, but it can be just HTML if you wish it.
- 3dGrabber 3y agoWhy would you insist to write the function name both before AND after the call? <DoStuff> args </DoStuff> vs DoStuff(args)
- iamsaitam 3y agoIs this the main argument? I think the simplest answer is boundaries. Taking into account how much nesting is involved in writing HTML, it's a clear benefit having a named boundary vs a closing parenthesis.
- 3dGrabber 3y ago> Taking into account how much nesting is involved in writing HTML which is another one of its flaws.
- iamsaitam 3y agoWhat would the alternative be? How can you design a UI without nesting things?
- xpl 3y agoToo much nesting usually signals that you should decompose it to smaller components. Same as with regular code and functions — overly deep nesting screams bad code. Honestly, JSX is just a verbose way of calling functions / constructing objects, which is probably OK if it was a language of its own (XML/HTML) — and even then, JSON/YAML won over XML — but makes little sense being embedded in a language which had functions & object literals from the get-go (JS)! The only reason JSX exists is because it was a cool marketing feature to convert existing PHP/HTML developers to React. And React succeeded mostly because of that. Not because JSX is cool technology-wise (it isn't). But because it hit the right spot in the right time.
- flying-pig 3y agoWell said! You got the point.
- lobsterthief 3y agoNot to me, it isn’t. It aligns with how the box model itself works.
- pastacacioepepe 3y agoMore like: <DoStuff args={...} />
- 3dGrabber 3y agoPlease no The {...} syntax is a non-standard extension to XML/HTML I think MS came first up with back in the day for XAML (WPF). It's a hack to "fix" a shortcoming of the base language. It does not compose, i.e. : <DoStuff args={<DoMoreStuff args={...} />} /> does not work.
- pastacacioepepe 3y agoThat would be <DoStuff args={...}><DoMoreStuff args={...} /></DoStuff> Still more readable than brackets hell like: DoStuff(DoMoreStuff(DoEvenMoreStuff()))
- 3dGrabber 3y ago^^^ Apples to oranges: <DoStuff args={...}><DoMoreStuff args={...}> <DoEvenMoreStuff args={...}/> </DoMoreStuff> </DoStuff> vs DoStuff(DoMoreStuff(DoEvenMoreStuff())) Both of them you would split into indented lines when they become too long. And 1 becomes too long much faster. Also with 2 you can do const todo = DoMoreStuff(DoEvenMoreStuff()); DoStuff(todo); where as with 1 you cannot.
- mitt_romney_12 3y agoWith JSX you can do const todo = <DoMoreStuff args={...}><DoEvenMoreStuff args={...}/></DoMoreStuff>; <DoStuff args={...}>{todo}</DoStuff>
- selfselfgo 3y ago[dead]
- xena 3y agoOh, this is literally Xeact. https://xeiaso.net/blog/xeact-0.0.69-2021-11-18/ https://xeiaso.net/blog/xeact-0.0.69-2021-11-18/
- __s 3y agoNot literally
- dspillett 3y agoWhile literally literally does not mean figuratively, people often use literally to say figuratively with extra emphasis, to the point where some dictionaries literally⁰ list figuratively as a secondary meaning for literally. Yet another example of language evolving through variations in common use that take hold. -- [0] literally literally, not figuratively literally
- codebeaker 3y agoWhy do people even reinvent this wheel every few months? Does the <1KB size even matter with modern caches and HTTP2? Does the amount of written lines of code matter when there's modern linters and tooling? Anyone can build a "reactive" type framework by following tutorials online now, they're super in vogue. Is my cynicism here warranted, or am I just jaded from 20 years of watching pendulums swing left and right and watching the wheel be reinvented over and over?
- pulse7 3y agoThe problem is not size. The problem is installation, configuration, dependencies, transpilation, IDE setup, etc. And here you have the plain old notepad with browser - nothing else...
- deleted 3y ago[deleted]
- robin_reala 3y agoThe amount of code matters when the lowest-performing Androids on the market have an order of magnitude less single core performance than a modern iOS device. V8 parse times have got much better over the last few years (they used to be a big bottleneck) but you’ve still got major execution cost leading to bad user experience.
- viraptor 3y agoThe code size is a poor proxy for performance though. React likely has some areas which are much more performant just because of development efforts, even if it's larger. If we want performance, that's the metric that should be public and clear.
- flying-pig 3y agoFWIW, VanJS's performance is very impressive. At least much better than React: https://vanjs.org/#performance https://vanjs.org/#performance
- __s 3y agoThis doesn't look too bad for pushing down minimal dom manipulation, since it includes reactivity Looking at my own use of solid, things this is missing are: - jsx - stores (having some way to hook into van's reactivity would address this, maybe digging into van.state internals there's a way) - onMount/onCleanup - For/Index/Show which helps handle efficient reuse, this could probably be built as a layer on top of vanjs
- glutamate 3y ago> jsx I don't agree, this syntax for html is much nicer than JSX when you get used to it. Converter from HTML at https://www.solenya.org/convert https://www.solenya.org/convert
- thinkingkong 3y agoThe whole “small footprint” thing is always weird to me. I understand that lots of people really want to squeeze efficiency out of every single kb but Im struggling to see where this is helpful. A single image, a single pixel from the marketing team, the actual application code, the page, etc are all going to dwarf the framework.
- nwoli 3y agoNot necessarily. Lots of jpegs go below the 1 mb mark (and tons of framework are bloated like crazy)
- subtra3t 3y agoI think you misread the title. The framework is 0.9kb, not 0.9mb.
- robin_reala 3y agoIt’s about execution cost, not size over the network.
- mpeg 3y agoI think this is why, for me, the future of JS are resumable frameworks like Qwik and Marko 6 – you get all the benefits of NextJS + React (composable UIs, state management, server-side code, etc) with no hydration, which is a big cause of sluggishness with web apps. Your code only executes when needed, and only that specific chunk of functionality.
- preciousoo 3y agoComing from living in third world countries where I had to ration data transfer, at speeds ranging equally from 50kbps to 1mbps, I appreciate these efforts greatly
- probably_wrong 3y agoI had until very recently a limited data plan for my cell phone in Europe, a plan similar to the one most of my friends have. The only websites that remained reliably accessible once I'd hit the 2Gb limit were HN and i.reddit.com (RIP). 90% of all other websites just time out. If anything, I wish we could force the marketing team to compress their images better.
- pard68 3y agoLove the use of functions to craft components. Such an undervalued way of writing a UI.
- whalesalad 3y agoclojurescript and elm would perhaps interest you =)
- pard68 3y agoI have struggled to use Elm because I rarely if ever need what it offers in my personal projects and at work we are a Lit shop. Love CLJS though, I use that sometimes for personal work when I have an urge to lisp.
- xiphias2 3y agoThis is where most libraries are going. Svelte 5 builds upon these signals / derivations as well, and I guess a bunch of other libraries. It would be time for them to get together and standardize on a signals library at this point that could be adopted to be a web standard and help interoperability between web components built with different frameworks.
- jrajav 3y agoI fully agree with the sentiment, but Svelte does not seem like a natural leader on that front since their version is a JS superset. Already a bit off the map for interoperability. Solid's attempt feels more promising since it's building on existing native functionality (proxies / getters), and has intuitive, low-footprint usage (just function calls and reference comparisons). Edit: It seems I'm not up to speed in fact, I hadn't seen Svelte 5 and runes yet, which are not compile-time. I will need to give it another try. I agree in general that signals and signal-based APIs are the future and definitely better than hooks at least, and a single agnostic standard would be good for everyone.
- badbotty 3y agoI tried solid and I didn't find it intuitive. Having your data behind proxies introduces more ceremony when splitting / combining props. I felt I was just moving the trade-off React makes when feeding a deps list to hooks to a different location. The proxies also made things hard to debug and you have to be careful about the language features you use with them. I also have often have smaller deps lists in React's useEffect when wanting to call a callback on the props because of some local state changes. I wouldn't want the effect to fire because the callback changed however. I'm not sure solid even supports that in its createEffect since it is all automatic.
- deleted 3y ago[deleted]
- Rapzid 3y agoMobX and chill. Works with React, Vue, Solid, and etc.
- wrsh07 3y agoFeels weird to seem to seriously represent your framework as being about size without including a comparison to preact - the obvious choice for a react developer looking to reduce their footprint. Preact claims 3kb on their site, and for a 3-4x savings you're going to need to be fairly compelling. I don't mind paying a modest cost for 10x or 100x improvements, but (call it Stockholm syndrome) I like react syntax
- __s 3y agoModern reactive UI frameworks get away from maintaining virtual dom. If you want minimalist vdom preact is a great choice. If you'd like to part ways with vdom while keeping jsx, try svelte or solid-js
- threatofrain 3y agoWhat are the long term theoretical benefits of vdom? Concurrent rendering?
- __s 3y agoAt least with solid, you can't do `const a = <jsx>` without caveats. Instead you have to store it as `const a = () => <jsx>` (which isn't quite the same, having problems managing state/renders). In React I was optimizing things by storing vdom in state/memo & then interpolating that exact vdom. Or sharing vdom in multiple places. Without vdom you can't throw jsx results around so haphazardly In solid there's also managing batching updates to reduce rerenders since it eagerly updates dom. It feels like one needs to be more meticulous
- deleted 3y ago[deleted]
- jrajav 3y agoThe flipside of this is that in React you are paying the cost of active vdom all the time, even when it doesn't pay off by optimizing large batched updates. In Solid, you sometimes have to optimize for some eager updates, true. That will have to be done at some point, though, when the situation calls for it - in either a specific or a general way. It feels natural to shift that optimization to the state layer, and completely eliminate the need for vdom, at the expense of some more thought and active, upfront work. It's a similar tradeoff to spending more time crafting static typing that works well, versus forgoing static types. The tradeoff seems to have good effect too - Solid seems much faster than React both on paper and in practice (my personal experience).
- theandrewbailey 3y agoThis is unacceptably huge compared to the similarly named Vanilla JS. http://vanilla-js.com/ http://vanilla-js.com/
- helsinkiandrew 3y ago> This is unacceptably huge compared to the similarly named Vanilla JS. It took me a minute to get it. 0 bytes uncompressed, 25 bytes gzipped
- wsc981 3y agoMagnitudes ...
- ping-monkey 3y agoTry to replicate a sample app made by VanJS with Vanilla JS and check the difference
- qayxc 3y ago
- helsinkiandrew 3y agoPreviously discussed 7 months ago (204 comments): https://news.ycombinator.com/item?id=36067983 https://news.ycombinator.com/item?id=36067983
- 3dGrabber 3y agoPeople complaining about lack of JSX, HTML angle-brackets: I don't get it. XML gets all the hate for being overly verbose (and for good reason [1]) however with HTML syntax, which is almost the same, everybody seems to be just fine... [1] XML is sooo nineties, the "modern" developer uses markdown. inb4 S-Expressions </rant> (...yes I know)
- sabellito 3y agoIt's a little more than that. Some people feel that XML is great to represent nested structures/trees, and that trying to do that with code is less readable.
- norman784 3y agoFor me it's about not to learn yet another new syntax, and HTML is here to stay.
- 3dGrabber 3y agoIf you know JS (or any other C family language), the syntax is not new. It's about getting rid of a flawed syntax. But it'll probably never happen because people are used to it and oblivious to change. Unless of course if one of the FAANG publishes it as their New FrameWork [tm], then everybody will jump on it, and people that don't are seen as "not modern".
- flying-pig 3y agoAgreed. JSX is a bug, not a feature.
- synergy20 3y agodoes it mean I have to add many things that are already in vuejs and react if I decide to use vanjs? what vanjs really brings to the table? the existing SPA frameworks are indeed super heavy and anything light and can get daily work done easier will be nice. after trying react for years I now switched to htmx with a simple backend, until there is a simpler to learn and use SPA(no SSR please) somewhere.
- jonatron 3y agoI wanted to try a vanilla JS version of the VanJS counter: https://jsfiddle.net/pdfzx3a9/ https://jsfiddle.net/pdfzx3a9/ Have people forgotten about event delegation? Surely the number of event listeners can get excessive in some cases.
- ralmidani 3y agoThis looks great! I love having the ability to bring existing React/JSX knowledge and be productive with VanJS, while also ditching the transpilation and build tool wildness that has afflicted the ecosystem. React and JSX were needed in 2013, but with the power and convenience packed into new ES standards and supported by modern browsers, React and JSX should be viewed as bloated polyfills at this point. It’s really heartening to see things trending back toward single script tags that help you avoid build tools, churn, and dependency hell. To that end, I’m leaning toward htmx for my own project, but what you’ve come up with looks really enticing as well.
- jopsen 3y agoHow is this different from: https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp
- thatxliner 3y agoWhat about https://www.arrow-js.com/ https://www.arrow-js.com/
- replwoacause 3y agoLooks awesome
- bgirard 3y ago<1KB is great and all, but part of the problem is that as soon as you add render blocking JavaScript you're adding a network round trip and JS on the critical path. <1KB might not feel like much, but it's not going to be very different than 10KB. Once you throw in non-trivial product code it doesn't matter at all. Either you should statically/server generate your site, or you have rich content that needs a client side app and you should pick a framework with rich features.
- simonw 3y agoIf you're worried about an extra network round-trip, <1KB is small enough that you could inline the entire framework into the <head> section of your document.
- bgirard 3y agoFrameworks need product code.
- flying-pig 3y agoWith bundler like esbuild, all JS code, including 3rd party libraries can be bundled into a single file. You don't need an extra round trip for a library.
- dclowd9901 3y agoA lot of the heft of React comes from its optimization and reconciliation code. Looking at the examples on the homepage, I’m struggling to see how this framework would efficiently make updates. It seems like it would just need to update the entire component tree down on any update. For any sufficiently large app this becomes very slow very quickly.
- ping-monkey 3y agoVanJS is a lot faster than React: https://vanjs.org/#performance https://vanjs.org/#performance. UI re-rendering in VanJS is kept at the local level as much as possible, which can be achieved without even the need of vdom
- itslennysfault 3y agoI love it. This feels a lot like Flutter's UI system (which I also love). Anything to move us away from JSX is a win to me.
- kevinfiol 3y agoI think this looks great and I'm excited to give this a shot. Also, shameless plug for my own micro JS UI library. No signals, just regular JS variables: https://github.com/kevinfiol/umai https://github.com/kevinfiol/umai
- AISnakeOil 3y agoWeb development makes me want to cry
- brap 3y agoI don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
- mikeryan 3y agoIt is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.
- jfengel 3y agoJSX does seem to fit that niche better than any other alternative I've tried. It pulls off a rather remarkable trick of avoiding the "uncanny valley" that you usually get from starting with a language and contorting it to do something different. JSX manages to feel just about right: it's plain-old-HTML when you want it to be, and plain-old-Javascript when you need an out. Still... I wouldn't mind writing in a truly standard language. You're "really" writing the DOM, and HTML and DOM are this godawful bastardization of a user-interface description language. I'd be slightly less grumpy to have a good DOM-writing library, and deal with its ugliness, rather than mix-and-match the domain-specific-language in with my actual coding language. I'd written myself a good Java version of this type of thing, and I found it kinda pleasant -- especially since it let me do HTML structure checking via the Java type checking. Typescript is -- God help me -- actually a pretty good language, and I'd be OK with actually writing my user interface structure in it, with the help of a good library. At least then I'm writing in only one language. That saves me time to go out and learn the godawful bodge of CSS to make it look pretty.
- lf-non 3y agoThe library looks nice dx wise but complete lack of any lifecycle hooks is a bummer. I get that minimalism is the core theme but to use any js ui lib that is not explicitly built around the same reactivity model you need to hook into component lifecycle.
- mrozbarry 3y agoLife-cycle hooks typically run as side-effects from state changes, so that would be your route to do something similar.
- lf-non 3y agoIf I want to do something like initialize codemirror when my component attaches to dom, I need an event/hook for that. I can't do that solely based on state subscription?
- whalesalad 3y agowe're coming full circle to $('<div>').appendTo(parent)
- Pesthuf 3y agoNot really. That kind of code makes it easy to render something initially, but absolute hell to update and keep your state and UI in sync.
- deleted 3y ago[deleted]
- gustavus 3y agoIt's the CIRCLE OF FRAMEWORKS! Dev: "All the legacy crap is too bloated obnoxious to use and has to much overhead, packaging, and training required to do even smiple things. I'm going to invent a simple lightweight framework from scratch that uses first principles to stay clean." Time passes framework starts to get used Random user: "I need to be able to dynamically modify table spacing in Elbonian based languages, whilst allowing for non-standard viewports to dyanmically load partial DOM changes while asynchronously displaying a cat falling over gif animation and the only way to do it in the framework is a bloated hack, any serious enterprise tool needs this, until you get it this is just a toy" Dev: "Well I guess that makes sense" Time passes: Hundreds of these random edge cases pop up, og dev is tired, the project gets moved to a committee, usually some drama pops up for several reason that have more to do about posturing than the framework itself New dev: "This framework is bloated complicated and has too many dependencies and layers of abstraction. After all what purpose on earth is there for me to have to configure whether or not I am using Elbonian derived language encodings that nonsense. I'm going to write my own framework that is lightweight and simple and does what I need it to without all this extra crap" IT'S THE CIRCLE OF FRONTEND!! AND IT MOVES US ONWARD!!
- simonw 3y agoAfter reading the tutorial at https://vanjs.org/tutorial https://vanjs.org/tutorial I was about to open an issue suggesting that they include constants with the SVG and MathML namespace, so that this: const {circle, path, svg} = van.tagsNS("http://www.w3.org/2000/svg") const {math, mi, mn, mo, mrow, msup} = van.tagsNS("http://www.w3.org/1998/Math/MathML") Could be expressed like this instead: const {circle, path, svg} = van.tagsNS(van.SVG) const {math, mi, mn, mo, mrow, msup} = van.tagsNS(van.MathML) ... then I looked at the code at https://cdn.jsdelivr.net/gh/vanjs-org/van/public/van-1.2.7.min.js https://cdn.jsdelivr.net/gh/vanjs-org/van/public/van-1.2.7.m... and realized that adding those constants would increase the size from 1729 to 1806 bytes - a 4.45% increase for a feature most people would never use. This thing is tight! Just for fun, I ran their minified code through ChatGPT to see if it could deobfuscate it. It did a pretty good job of guessing sensible variable names for things: https://chat.openai.com/share/9dac0b13-7b24-409a-9cc1-4946670d27e1 https://chat.openai.com/share/9dac0b13-7b24-409a-9cc1-494667...
- NetOpWibby 3y agoOh wow, didn't know ChatGPT could de-obfuscate code!!
- dimeatree 3y agoIt does a good job to give some analysis on malicious code snippets
- dev1ycan 3y agoIs there a reason they compare bundle sizes with for example jquery when every framework ends up importing jquery anyways, since animations are a headache and are often readily available already with jquery?
- flying-pig 3y ago> when every framework ends up importing jquery anyways Evidence?
- leke 3y agoThis kind of reminds me of Mithril, although I don't really have much experience of that either.
- deleted 3y ago[deleted]
- fyzix 3y agoThe author seems to be chasing the small size trophy at any cost...to the point where he's using "var" instead of "const" because it saves a few bytes. Not indicative of someone serious...
- flying-pig 3y agoNo offense. What exactly is the cost of using "var" instead of "const"? You seem to pretend it to be a big deal.
- fyzix 3y agoIt sacrifices maintainability and robustness to save a measly 80 bytes (I counted).
- briantakita 3y agoThe author works as a back end engineer @ Google. I appreciate his "outsider" approach as it is quite a bit simpler than other UI libraries & even reactive state management libraries such as Nanostores. I'm sure if he were in a different development role, his technique would be refined to account for full stack development use cases. I don't mean to throw any shade on Tao. He is very talented & his approach is beneficially novel. I just don't think he as much experience what life is like as a full stack (or front end) developer as many here. I forked his work to create relementjs & rmemo. Tao didn't want to support server side reactivity & I heavily use it. Also, Andrey (maintainer of Nanostores) didn't want to add my PR for autosubscriptions due to the complexity cost that would be added to Nanostores...So I wrote my own set of libraries. I hope library simplicity trends more because it is very nice to work with simple libraries. Tao's approach is sound. He just relies on the DOM to manage the reactive state, so SSR reactivity would require a different approach. I ended up using WeakRef, which is significantly smaller than the approach used by traditional reactive state management libraries.
- ejanus 3y agoWhere is your repo link?
- deleted 3y ago[deleted]
- earthboundkid 3y ago> 道可道，非常道 > (A rule that can be told by words, is not the rule that should universally apply) I'm curious where the dev got that translation or if they made it themselves. I have translated it before like "No method that can be explained is universally applicable" but I haven't seen many other translations like that.
- taoxin 3y agoHere is the break down of my understanding about the philosophy described in 道德经: 1. There might be some universal rules about the world. 2. There are limitations in human's understanding and human language. 3. For all the rules that can be described in human language (which is subject to the limitations in 2), they can't hold universally. Putting into the context where the words are cited. Any claim (in human language) about programming like "you should program in this way" is most likely not universally sound. Of course a philosophy book 2000+ years ago can be interpreted in a different way. Happy to see the elaboration of your understanding "No method that can be explained is universally applicable".
- earthboundkid 3y agoThe word dao literally means “road” but by the time of the DDJ, it had come to mean “way of doing something” and “speech that explains how to do something”. Interestingly, in Greek “method” is meta + hodos and hodos means “road” so it’s an etymologically appropriate translation.
- taoxin 3y ago道 (dao) means "the way of doing thing" in modern-day Chinese as well. For instance, 王道 means the "the way of governing". 路 is more common for the literal meaning of "road", though 道 has a meaning of both "road" and "waterway" as well.
- briantakita 3y agoOne huge benefit to VanJS is it's simplicity. It is far easier to fork than most other UI component libraries. I did it writing relementjs & rmemo. I encourage others to fork it as well. VanJS is well written. You get a reactive state management library (on the browser side) & a UI renderer in < 150 LoC. Very impressive. I encourage anyone interested to experiment with this. It has been very fruitful for me. In case anyone is interested, here are my forks. https://github.com/relementjs/relementjs https://github.com/relementjs/relementjs https://github.com/rmemo/rmemo https://github.com/rmemo/rmemo, which exports https://github.com/ctx-core/ctx-core/tree/main/rmemo https://github.com/ctx-core/ctx-core/tree/main/rmemo. Note that rmemo also supports server side reactivity.
- dimeatree 3y agoState management seems a bit counter intuitive at a glance. I found this statement to be confusing; https://vanjs.org/tutorial#state-val-is-immutable https://vanjs.org/tutorial#state-val-is-immutable While you can update State objects by setting the val property, you should never mutate the underlying object of val itself. Then beneath is an example of the following; const text = van.state("VanJS") ... input({type: "text", value: text, oninput: e => text.val = e.target.value}) Which looks like a mutation - after reading a bit more around it is clearer that .val has a setter; but at a glance it just isn't obvious what is happening which I feel isn't intuitive.
- graphememes 3y agoYou can just use Mithril. https://mithril.js.org/ https://mithril.js.org/
- throwat2341 3y agoIt's too late for me. I, like Douglas Crockford, am completely done with JavaScript [1]. HTMX, LiveView, WASM, Dart, ClojureScript, Kotlin, ScalaJS, Dioxus -- There are lots of options folks. We don't need to surrender to the tyranny of JavaScript. [1] https://www.youtube.com/watch?v=lc5Np9OqDHU https://www.youtube.com/watch?v=lc5Np9OqDHU
- mediumsmart 3y agoThis looks great. But I replaced my last JavaScript use-case (fading image slideshow) with a css solution today so you will have to make this exciting journey without me.
- seanlaff 3y agoThis is cool, though I think a table-stakes example that is missing is how to do a network request. I see the stargazers example but that entire component is awaited, which doesn't mirror the common case of async fetch in response to user input, in which the response is fed to sub-components. The stargazer example leaves me with questions like- are components both async and non-async? What if the component re-renders due to other state changes, is my network request fired more than once? Do I have a "component coloring" problem where once one subcomponent is async, the entire parent hierarchy has to be? Im sure there's answers to these questions if I read the docs, but as a curious passer-byer an example mirroring this common ui pattern would answer a lot of questions for me!
- taoxin 3y agoIs this is what you are looking for? https://vanjs.org/vanui#await https://vanjs.org/vanui#await
- seanlaff 3y agoHmm, maybe! Is that the idiomatic way to do async? I was thinking something along the lines of this, which react devs will have written a variation of plenty of times :) import { useEffect, useState } from "react"; const GithubUser = ({ login, avatar_url, html_url }) => ( <div> <img src={avatar_url} style={{width:40, height:40}}/> <a href={html_url}>{login}</a> </div> ); export function App() { const [stargazerResp, setStargazerResp] = useState([]); const [repo, setRepo] = useState("vanjs-org/van"); useEffect(() => { fetch(`https://api.github.com/repos/${repo}/stargazers?per_page=5`) .then((r) => r.json()) .then((r) => Array.isArray(r) ? setStargazerResp(r) : setStargazerResp([])); }, [repo]); return ( <div className="App"> <input value={repo} onChange={(e) => setRepo(e.target.value)} /> <ul> {stargazerResp.map((s) => ( <li key={s.login}> <GithubUser login={s.login} avatar_url={s.avatar_url} html_url={s.html_url} /> </li> ))} </ul> </div> ); }
- aabbcc1241 3y agoThe syntax looks similar to dom-proxy [1] [1] https://github.com/beenotung/dom-proxy https://github.com/beenotung/dom-proxy