Really appreciate the write-up! ππΌ
Really appreciate the write-up! ππΌ
π€¦πΌββοΈπ€¦πΌββοΈπ€¦πΌββοΈ
Very appreciative of this ππΌ
Oh em gee, a talk filled with X-Files gifs? This might be the best conference ever #ffconf
Loving Sergès Goma's #ffconf talk on code cults. Am I a React cult survivor?? I think maybe...
Alright #ffconf, let's do this!
Thanks Burton! Definitely agree.
Only one month until @ffconf.org! I get to talk about our journey with web components, while sharing the stage with some awesome speakers π
See you there? ffconf.org/tickets/
Kinda disappointed to not see MySpace on here...
www.webbyawards.com/thewebby30/
When you've been in a year-long battle to convince teams that your coded DS component packages will help them, and an engineer tags you out of the blue suggesting your component is a far better alternative to implementing something new because you've already done the work for them π₯Ή
I think I'd assumed after moving from full stack to frontend and then specialising further as a UI Engineer, that I'd spend pretty much all my time writing frontend code... and yet here I am again lost in a sea of yaml trying to get pipelines working.
Published another of our #FFConf speaker interviews today. This time, pleased to introduce Hannah Clarke (if you're on bluesky, I've yet to find you!) on "An Uncomfortable Place" about building framework-agnostic components.
Get your ticket and see it IRL, interview here: ffconf.org/articles/202...
ππΌ over here!
While the day job is more design-side, itβs been pretty awesome working on a side project with @hannahc.bsky.social, learning a load of nextjs, api architecture, Supabase and all kinds of stuff
You don't have to - stencil will generate a types file itself if you set the option in the config. But for consistency with our existing setup I've been adding the extra step in a custom script.
Currently only outputting for React, so can only speak to that, but Stencil can generate a types file when it builds components. We wanted individual types files per component in our React library so I wrote a script to generate these after Stencil builds and added them to the wrapper. Works well.
This week I have learnt that a lot of unnecessary stress and confusion can be avoided by clarifying what you mean by terminology you assume everyone uses in the same way. In this case - "components". We meant buttons, links and other atomic stuff. They meant entire dashboards.
Research question for you - if someone shares a playlist (or a track, album, anything) that you like the look of from Spotify, but you're an Apple Music user, what do you do?
(Swap either streaming platform for one you don't use and one you do)
#music #musicsky
There's definitely an element of that in there too π but there's a lot of Stencil specific stuff that I've had to just trial & error to find the right solution.
I've been using Stencil to build our Design System web components and it's really great, but the amount of time I've spent figuring out things that are a little too niche for the documentation is insane.
Time I could be using to write up the things I've been figuring out without documentation... ππ
Exactly! The irony being that not all products use React, but seems the suggestion is they should "just all start using React instead". π€¦ββοΈ
(I'm just gunna keep building them as we've planned until we're told not to... Who cares how they were made if they work the same?)
If you're getting React components at the end of it, why does it matter how they were built? Not to mention the long term future proofing benefits we get from web-components. Urghhh π£
After spending a lot of time getting our Design System infrastructure ready to go using Stencil for web-components, writing custom processing scripts to make generated React components *perfect* for React product devs, being told we should just be building in React is so incredibly demoralising.
Feel like I should get time-off-in-lieu for the nights where I try to debug an unresolved issue in my sleep. Dreaming about an inconsistent build script is in no way restful π΄
π―
I'm on a team building a Design System for products using multiple frameworks, which we can cater for on the web side using web-components, but my current thinking is a mobile library will need to be a completely separate entity. There's only so far you can go with framework agnostic code.
I'm worried that this might be the case... Luckily I have a lot of React experience so can spot the bs, but if it comes down to who can shout louder, I'm concerned they're going to win.
Hmm interesting!
The only explanation I can think of in this case is it's someone getting overly enthused about react-native-web, but as our product is predominantly web based (with a supporting mobile app) it seems wild to move to a framework built for mobile app development.
I've previously had to build a web app using React Native and it's not a straightforward experience, I don't see why this would become the standard.
#React #ReactNative #ReactDevelopers #webcomponents
Hey #frontend developers! Someone has put forward the argument that "the future of React is React Native" as a way of fighting a Design System built with web-components (outputting wrapped components for React).
Has anyone else come across this? I've not heard anything that suggests it's likely.
I wrote a thing about codemods. I don't really know where to share it, so I'll just leave it over here in case anyone needs it.
medium.com/@_hannahc_/c...
#frontend #javascript #react #typescript #webdevelopment #designsystems