#DevLog: #Anklang #SolidJS Influx
Fixed some of my #LitElement bugs by migrating to solid
Refactored & simplified modal dialog creation
Goal: Robust UI with modern reactivity patterns!
#DevLog: #Anklang #SolidJS Influx
Fixed some of my #LitElement bugs by migrating to solid
Refactored & simplified modal dialog creation
Goal: Robust UI with modern reactivity patterns!
DevLog: #Anklang Tech Stack Modernization
Migrated to #TailwindCSS-4 + #Vite (#HMR rocks)
Replaced Vue with SolidJS signals + #LitElement
Fixed sidebar overlaps, double-click bugs
Quirk debugging still ongoing, but progress is solid!
Disappointed to find significant typechecking issues in `lit-analyzer` (which powers `lit-plugin` for type checking in `html` templates), such as disallowing assigning a `string[]`-typed value to an `Iterable<string>`-typed property (and various other similar type issues that seem to go back some years: https://github.com/runem/lit-analyzer/issues/381).
Maybe I'm just missing something? What do others do to ensure type checking in Lit templates works correctly? I'd love to find out I'm just being dense as per.
@tjcrowdertech sometime #litElement. Lots of times #webComponents and know it will find the right people…
What have you been making?
Functional Web Components with LitElements.
For practice and learning i decided to create a #UIFramework to make LitElements more functional. i like the idea of webcomponents and #litElement, but i liked the #reactSyntax for what i see as "more readable" and "more maintainable" code. So i decided to create a simple todo app using a #functional approach with #LitElements.
Im investigating additional features and improvements so i dont reccommend anyone to adopt using this yet. The implementation is far from finished, but seems to be working enough to test.
Future improvements on this im looking into are:
- bottom up state management
- encrypted state persistence at rest
Blog: https://positive-intentions.com/blog/dim-functional-webcomponents
GitHub: https://github.com/positive-intentions/dim
Demo: https://dim.positive-intentions.com/?path=/story/components-todo--basic
How To Create Functional Web Components
Blog: https://positive-intentions.com/blog/dim-todo-list
GitHub: https://github.com/positive-intentions/dim
Demo: https://dim.positive-intentions.com/?path=/story/components-todo--basic
Maybe I should give #11ty a shot with the #lit plugin..
https://github.com/lit/lit/tree/main/packages/labs/eleventy-plugin-lit#lit-labseleventy-plugin-lit
This would give me static #HTML generation at build-time and then I can import the #LitElement at client-time to do dynamic stuff.
Not a huge fan of classes in #JavaScript, but I can get over that.
Wails: Coding in Harmony, Not in Distress!
The WPEs are b a c k!
We’re going to be doing a bit with the Wails project this year, so let’s start off nice and slow with a small project to get our feet wet before diving in head first.
Wails…who dis?
Wails is a project that enables you to write desktop applications using Go and web technologies. It’s a lightweight and fast Electron alternative for Go, allowing you to build applications with the flexibility and power of Go, combined with a rich, modern frontend. Wails uses a purpose-built library for handling native elements such as Window
, Menu
s, Dialog
s, etc., so you can build good-looking, feature-rich desktop applications.
The amount of Go and JavaScript required is minimal, at first, and you can 100% get by with Kagi, Perplexity, or just some keen internet searches (and poking through the Drop history for Go and JavaScript resources). I’ll prove this with the app you’re going to modify.
Wails use of these technologies means you can (for the most part) turn any web app you make into something that you can distribute as an actual app to folks. While I’m more of a fan of native apps, this can save a ton of time and reduce cognitive load…something I think we’ll all need this year.
Getting Started with Wails
To start with Wails, you need to install it first. You can install Wails using the Go install command:
$ go install github.com/wailsapp/wails/v2/cmd/wails@latest
After that install finishes, you can validate it with:
$ wails doctor
In the wall of output you should see “SUCCESS” near the end.
Now, we can initialize a new project!
For this tutorial, we will use the Lit template:
$ wails init -n wails-tutorial -t lit
As longtime Drop readers know, Lit provides a very lightweight and sane wrapper over standard Web Components.
Now, do:
$ cd wails-tutorial$ wails dev
A bunch of text will scroll by and you should see an app screen that lets you enter in some text that will be parroted back at you.
The directory structure looks like this:
wails-tutorial├── README.md├── app.go├── build│ ├── README.md│ ├── appicon.png│ ├── darwin│ │ ├── Info.dev.plist│ │ └── Info.plist│ └── windows│ ├── icon.ico│ ├── info.json│ ├── installer│ │ ├── project.nsi│ │ └── wails_tools.nsh│ └── wails.exe.manifest├── frontend│ ├── dist│ │ └── gitkeep│ ├── index.html│ ├── package.json│ ├── src│ │ ├── assets│ │ │ ├── fonts│ │ │ │ ├── OFL.txt│ │ │ │ └── nunito-v16-latin-regular.woff2│ │ │ └── images│ │ │ └── logo-universal.png│ │ ├── my-element.js│ │ └── style.css│ ├── vite.config.js│ └── wailsjs│ ├── go│ │ └── main│ │ ├── App.d.ts│ │ └── App.js│ └── runtime│ ├── package.json│ ├── runtime.d.ts│ └── runtime.js├── go.mod├── go.sum├── main.go└── wails.json
Here are the core files we’ll be tweaking:
app.go
contains the Go back end functions we’ll be exposing to the JavaScript front endfrontend/index.html
is the entry point for the appmy-element.js
is the Lit web component that handles the interactivity (we’ll be renaming this).In the default app, Greet
in app.go
is called by my-element.js
. Here’s what that function looks like:
func (a *App) Greet(name string) string { return fmt.Sprintf("Hello %s, It's show time!", name)}
The func (a *App) Greet(name string) string
is a function signature the Wails dev tools looks for. It will automagically generate glue code for the JavaScript parts, and you can use complex function parameters and return values. This one takes in a string, surrounds it with some basic text, then returns it.
You should take some time to change what’s in the Sprintf
, rename Greet
(and use the new imported name in the my-element.js
) and tweak what the render()
returns in my-element.js
before continuing. It might also be a good idea to read through the official walkthrough.
Making A “Real” App
Rather than blather a bunch (it is your WPE, after all), I’m going to link you to Codeberg where there’s a modified version of this template project that:
The core change to app.go
is this function:
func (a *App) FetchOpenGraphTags(postURL string) (map[string]string, error) {fmt.Println("FOGT:", postURL)og, err := opengraph.Fetch(postURL)fmt.Printf("OpenGraph: %+v\nError: %v\n", og, err)return map[string]string{"title": og.Title,"description": og.Description,"url": og.URL.String(),}, err}
I added some printing in there so you can see messages appear in the terminal console while the app is running.
When you run wails dev
the glue code is, again, automagically generated so the JavaScript side can call that function via:
async fetchOG() { let thisURL = this.shadowRoot.querySelector('input#url').value console.log("fetchOG") FetchOpenGraphTags(thisURL).then(result => { console.log('fetch opengraph tags:', result) this.tags = result; this.requestUpdate(); });}// I’m showing this here, but we’ll talk about it in the next WPEasync connectedCallback() { super.connectedCallback();}
The fetchOG
function is called in render()
when the button is pressed:
<button @click=${this.fetchOG} class="btn">Render</button>
You can use Developer Tools from the running app to watch the console messages go by (very useful for debugging).
Your Mission
Your goal is to (a) successfully get this modified app running and (b) utilize more OG tag fields and display the entire set of OG tags in a much nicer way. Extra points for adding another Golang back end function that you need to call from the JS side.
FIN
Today’s WPE sets a solid foundation for future ones, and we’ll be having tons of fun with it as we layer in DuckDB, SQLite, WebR, Pyodide, and more over the coming weeks/months. Give a shout-out or reply to this post if you have any questions/issues.
The first Bonus Drop goes out this weekend to paid subscribers! (The refunds from the transition from Nazistack should be out soon…I keep checking on the status and will follow up next week if there’s a delay.)
Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
https://dailydrop.hrbrmstr.dev/2024/01/05/drop-399-2024-01-05-weekend-project-edition/
"in a way you can think of a lit element is like a computed effect of a signals although our system kinda works like a push system instead of signals that often have a pull system" ~ @justinfagnani
It's cool that #Lit is integrating with #Signals.
It feels like we've been circling around this design pattern for decades; they've been called Observables, Pub/Sub, State, Context, etc.
STOKED to hear that there's discussion around standardizing and adding Signals to the #webPlatform!
https://www.youtube.com/live/ri9FEl_hRTc?si=-oztbFGgLG0f9aXJ&t=1636
It's super cool that #Lit is supporting standard #javaScript #decorators, but I'm still not going to use them!
Maybe one day when they don't need to be transpiled anymore.
I think that #shadowDOM solves #css's problems and #lit is right to scope styles to the element.
#lit is getting a "context" api https://www.npmjs.com/package/@lit/context
It seems to work like #React #Context, but it's an open standard that other #webComponent frameworks can apparently implement.
If you were building an SPA with no build step, which framework would you use?
Comment if you don't see your choice. Boosts welcome!
“React Is Not Modern Web Development”
@jaredwhite’s personal thoughts on a great entry by @collinsworth into the growing body of work which details why greenfield #WebDev projects are better served by other frameworks…or none at all.
More adventures in using #jsdoc with #litelement:
The LitElement superclass generates reactive properties at runtime based on a static object in the subclass. Type systems don't like this--the types don't show up on the superclass because they're generated, and they don't show up on the base class because `ChildClass.properties.property` is not the same thing as `new ChildClass().property`
I've finally started my devlog thing about creating an advanced data grid using #LitElement. https://dev.to/paulhmason/developing-a-data-grid-using-litelement-part-1-48pl
.
One thing that gets me really excited about #webcomponents is the ability to change course.
I had a project written in #vanillajs , but that was a pain, so I started writing new code using #webcomponents . But that was still a pain, so I decided to write any new components using #litelement .
For my next project I’m thinking about using #hauntedjs and #ionicframework , but there’s peace of mind knowing that if I don’t like it I can go back to #litelement or #vanillajs .