DEV Community: Tim Bendt

Dev Journal: Maps in Apps

Tim Bendt — Fri, 03 Sep 2021 11:36:00 +0000

Yeah I’m posting more gifs. Sorry, not sorry.

Read some more of that book last night. Still not sure what to do about everything.

8:54 AM

Calling the doctor now just to see if my old prescription helps out at all again. One of the problems with medication is that I don’t know if it really works if I skip so many days. I often skip taking any prescription about 1/3 of the days of the week. Consistent habits are not easy for me.

9:05 AM

OK, only on hold for 5 minutes that time. Got things sorted out.

Time to catch up on slack…

9:43 AM

Mushroom growing from start to finish.

10:01 AM

The US Army operated A Small Nuclear Power Plan in Greenland in the 1960s

10:38 AM

Mapbox in react isn’t rendering the base-map tiles. It seems like maybe I’m getting some sort of authentication error using the mapbox api. I’m gonna drop this customized map component and just use the base library components.

11:21 AM

Success! Got the react native app to render a map with the same large GeoJSON object in a webview and compare it with a map rendered a native map component.

video demo

I would say, that on my iPhone SE2 from 2020, the interactions is roughly equally good. The line drawing isn’t as clear in web-view as in the native component.

I should try to compare raster tile layer performance too.

12:57 PM

Doing some planning for a hackathon in 2 weeks. Gotta figure out the scope of what we will tackle. I’ve done a lot of miro planning for this developer portal already, but don’t want to overwhelm people with everything in my mind. I tend to run on ahead and then I expect people to get annoyed if I’ve thought too far ahead of where we are at in a project — this might be one of those strengths of ADD that I need to learn to capture and not be ashamed of.

1:01 PM

My wife brought me a salad for lunch. Thank you dear.

2:21 PM

Great conversations about frontend architecture. On the surface we were talking about shared state management and offline syncing functionality. One of the classic hard problems is cache invalidation. But more deeply the question came up, how do I help other frontend developers communicate and listen to the other devs that rely on their expertise. What is the wedge that’s drving these developers apart. How do we improve our listening and empathy as an organization…

Dev Journal: React native and webviews

Tim Bendt — Thu, 02 Sep 2021 11:15:00 +0000

Let’s get this going again.

I have some meetings today. I have a call with a client about design work at the end of the day. I still need to call my doctor. I still need to test out a webview in a react native app. Writing these posts is like journaling during the day.

Last night I checked out a book from the libarary about ADHD. I feel like I need to take this seriously and start really paying attention to this side of myself — not just be embarassed and ashamed because of the stigma around having a “disorder”. I could find coping mechanisms and look for opportunities to use my strengths, but I have a deep-seated belief that ADD makes me a bad worker, and it will get me fired.

9:54 AM

Great meeting about our big project, it kept me engaged with problem solving. Now, I think I’m going to try to load the web view in the mobile app like I started yesterday.

10:02 AM

My iPhone doesn’t have VPN access to the necessary dev servers. Need to run the web application container locally so I can do a real tests.

10:49 AM

Distracted with an article about mid-century cryptography machines. How amazing would it be to build a purely mechanical or maybe an electromechanical crypto device.

11:11 AM

Trying to make some progress. Discovering lots of little issues with the container react application. Like some bizarre browser detection feature.

I mean this works… technically. So can I get a mapbox map to show up here? If I can get the same map and data to render in both ways then this test will be done.

3:25 PM

I had another good meeting. I like filling up my day with meetings like that, I feel productive despite myself when I can help make decisions and discuss problems. Now it’s time for a little design meeting with my longest-running freelance client. We manage to do some good design work, and it’s almost all on the phone while I work in figma and he watches me. Some designers would probably lose their minds. I feel really proud of the work we did to re-design hundreds of screens of functionality over the last couple of years.

5:24 PM

Did some good work today. Did not call my doctor. Took a short nap over lunch. I never got past that stupid unsupported browser warning. So I’m going to have to yank all of the features out of this web app and just make a really minimal reproduction app that doesn’t have any of the login stuff in it tomorrow. And then I need to figure out some good answers about offline sync options.

Dev Blogging: An Attempt to Maintain Focus

Tim Bendt — Wed, 01 Sep 2021 11:15:00 +0000

I want to put my effort and focus into my job. I’m finding it difficult lately. For various reasons I’m not feeling very productive, seeing a decreased amount of focus during the day. Yesterday I was able to focus for a few meetings, but the rest of the day I was distracted constantly. Then about 4:30 I felt the energy drain out and my mind felt fuzzy and I was suddenly able to focus. 45 minutes of productivity per day is not enough.

The honesty is difficult. This blog has not been about things like this in a long time. I don’t like the idea of publishing these thoughts forever, they are pretty cringe. At the same time I’ve been watching youtube channels where people do fun projects and also just show the real side of themselves. I don’t think I can do video right now, but I can write and publish a blog. And it might help me when I feel like I need to just get some of the thoughts out of my head. ADHD is difficult to manage and having a place to pour some thoughts out might help.

So that’s this post: a log of my thoughts and accomplishments from one day. An account of what I’m doing to deal with various challenges and tasks.

Today I plan to do the following:

Have several short meetings about current projects.
Edit and Post this file at the end of the day.
Call and set up a Doctor’s appointment.
Create a react-native test application with an embedded webview that can load with injected authentication tokens.

This file will be updated as I proceed.

9:16 AM

Just wrote the above. Listening to Pandora station “Tiësto Radio”.

Installed https://github.com/react-native-webview/react-native-webview in my test project. It’s an expo app. Something weird happened to my project. The start script changed form expo start to react-native start. When I run react-native run-ios it starts up a very slow xcode build process.

I have about 1 hour until my first meeting of the day.

9:29 AM

I did somehow get the simulator to open my project.

expo start --dev-client then click the link in the web UI “Run on iOS Simulator” which opens a custom URL scheme link on the device.

It shows the app with custom native code inside it. Now can I get it to run on my actual device?

I want to skip the EAS build service for now. Can I just use the built in Apple tools? Plug in my iphone with USB. Launch XCode. Apple Docs. Add my work apple id to the accounts preferences in XCode. Change the project settings the associate with my work team for apple developer program membership.

Receive error in XCode:

Failed to register bundle identifier
The app identifier "com.timbly.donewithit" cannot be registered to your development team because it is not available. Change your bundle identifier to a unique string to try again.

Wat? Go make some more coffee. Just opened a new bag of “Late Night” from Methodical Coffee. Dark roast provided by bottomless.

9:54 AM

Worrying about tornadoes.

9:58 AM

If the proof of concept app doesn’t run on an actual device it doesn’t count as working in my mind. It’s important to carry test projects through the lenght of the development cycle. We call them tracer bullets sometimes. There’s not a lot of meat on the bones, but the project needs to traverse the full length of the process to find any gotchas.

Changing the bundle identifier to something else fixed the error in xcode, because I created the project and gave it a bundle identifier before I added my new apple ID that’s associated with a developer account.

10:05 AM

Build errors relating to expo.

Attempting to close xcode and open the .xcworkspace file instead

It’s building for longer - so this feels promising.

No, it failed in the node scripts.

Googling

Attempting: brew reinstall watchman

Requires XCode command line tools. Attempting xcode-select --install

11:26 AM

Two meetings. Need a break. Time to make some lunch and then watch some youtube.

12:00 PM

I had a confusing meeting that was full of information that I don’t know what to do with it. I have enough to keep me busy this is a confusing thing to try to figure out.

12:21 PM

I feel so lazy. I can’t do anything.

YouTube is stupid. There’s nothing on there. I don’t want to play games.

Time to call that doctor.

Reinstalling watchman again while on hold.

It’s weird that macOS is version 11 now. It’s been OS X v 10.x for almost 20 years.

3:38 PM

Got sick while on hold. Really sick to my stomach. Had to lay down. Took a long nap. I feel like a failure. Back up and trying again. OK, let’s see if the stupid project will build again.

3:43 PM

OK the development app started on my iPhone but I can’t get it to connect to my launcher.

3:50 PM

OK, got it figured out. It seems to be just my laptop’s IP address and port 8081. And it reloads when I change my JS. Now I can start testing it for real on a real device. Success!

4:05 PM

Love this channel: https://www.youtube.com/watch?v=fNxcOON1VNM

Outcomes

Meetings: partial success, had to skip 2 while sick

Posting this file to my blog… waiting until the next day.

Call and set up a Doctor’s appointment: fail.

Create a react-native test application: Partial Success. Still need to test the webview and the auth tokens.

Reduce Software Delivery Cycle Time and Switch To Github Actions

Tim Bendt — Wed, 14 Oct 2020 18:15:00 +0000

At Invisible we have a small but focused team of engineers that want to ship quickly. We are marching towards a goal of building a company and technology platform that can employ people everywhere in the world to do knowledge work at a fair wage. We manage complex project and operations teams with our custom tools, so we have a lot of software components that need to be developed and maintained.

We have adopted a monorepo structure for our platform so that everyone on the team remains in tight sync on what is happening around the different parts of the company. This also allows us to maintain some level of coupling between front-end and back-end services without creating multiple PRs on different repos. The unanticipated cost of the mono-repo for us was the time our CI pipeline took to run.

We were on CircleCI and had configured our CI test jobs to run all of the tests for every service in parallel every time we push code to a Pull Request. This configuration is perfect if you need to make sure that one service wont fail when another service or package changes. We treat our entire platform as one product, even though certain members of the team focus on just one part of the platform most of the time. But, our PR test runs were very slow, often over 20 minutes. This was happening because of several configuration choices we made early on, including running yarn install with lerna across every service and package up front then caching, which resulted in a 900 MB workspace cache file that needed to be downloaded for every successive step in the CI work-flow.

A slow test run time is annoying, but it became unbearable when we started insisting on a linear git history for our master branch. This setting means that every PR has to be re-based any time another PR is merged by someone else. Since we often have a dozen or more active PRs being worked on in one repository, this timer would have to re-start many times each day. Developers would make a change to code, see the test results come back, but the master branch had already been merged into by someone else. The owner of the PR would need to go back, re-base, force push, and start waiting for tests to finish all over again. Getting a feature to staging would often take an hour of sitting and waiting, and coordinating with other devs. Deploys to production often required manual intervention by a developer using a command line tool.

The core problem here is “tight coupling”. One team’s ability to ship is impacted by another person or team’s actions (merging first). Developers were prevented from finishing their work by circumstances outside of their control. With a structure like this, each developer we add would slow down every other person and team, that’s inverse efficiency scaling! Adding more people slows us all down! On the road to speed all instances of tight coupling between teams and services need to be eliminated.

This resulted in a very slow “cycle-time” — the time it takes to get from PR open to deployed in production. Every time a developer has to switch contexts and wait for an async process results in massive inefficiency.

We began outlining what we wanted to change about our CI configuration and created a goal of every CI test run being finished in less than 5 minutes. And every deployment script finishing in less than 5 minutes. Here’s how we configured our work-flows to do that.

We use path filtering in actions so that only the services that have changed actually run their unique tests.
We parallelized our runs so that multiple kinds of tests run at once.
We utilize small caches, unique to each service, instead of one big cache, so it can be downloaded and decompressed in seconds.
The only “global” tests are very short linting tests that don’t require as much installation and setup time.
We added a check to our back-end service that spots any breaking changes to our graphql schema and stops developers from shipping breaking changes, which helps eliminate another point of tight coupling between services.

After these changes our PR test suite runs between 1 and 4 minutes. All of this has significantly improved our cycle time. Everyone on the team can feel how much faster they are able to move with these shorter waits. We are also able to deploy more confidently because we know changes and fixes will be relatively quick and cheap to ship as well.

The switch from Circle to Github Actions will impact our bottom line as we will be using fewer minutes of compute time and we can use lower cost compute resources since each work-flow is doing less work. We can also take advantage of the 3000 minutes that are included with the Github pro team plan we were already paying for.

We are going to add a few more lint checks in the near future, and improve our automatic syncing of issue status in JIRA using these actions. I’m very excited about unblocking our engineering team to move faster. Instead of slowing down as we add more engineers, we can ensure each developer on the team is able to ship more often and more confidently.

The Bridges Between Design and Code

Tim Bendt — Thu, 30 Jul 2020 18:15:00 +0000

The problems with design-code hand-off are still manifold. I’ve been doing this for like 20 years and the process of turning visual direction into interactive applications is still fraught. Here are a few hints and principles to help you understand where this problem space has evolved lately.

Use Figma, but it’s not magic. Figma is an excellent design tool that is more accessible to devs since it’s web-based and collaborative. Devs get better access to measurement tools, colors, and specific CSS values that can be forklifted into a component, but honestly that saves us 2—5 lines of code in the component implementation, so don’t get hung up on that.
Don’t try to keep your static designs perfectly up to date with the work that makes it into production. Design tools are best used for creating a point-in-time snapshot. That snapshot will be attached to a story, ticket or issue in the project management tool, directing what developers should be creating. If the first implementation was sloppy and rushed because of deadlines, then put another story in the next sprint and keep circling in on that perfection until the product manager tells you to stop.
Developers should not be allowed to push code to production without someone reviewing it for proper reuse of components and consistent usage of design token values instead of hard-coded colors, fonts and sizes.
The designer needs to start with a systems and tokens mindset. They have to create reusable symbols that stick to a strict set of font styles, and colors. These values need to be synced with the code component theme values constantly. Also, the designer should have symbolic representations in their design tool that closely match up with the components that the developers have created.
A documentation site or app for you system is nice, but quickly turns into so much useless static artifacts if it’s not tightly integrated with the code that runs in production. For this reason we use Docz to write markdown with lots of integrated live examples of everything the component API is capable of.
Having a designer that knows how to write CSS and HTML is incredibly valuable. Working in the correct medium of the web is a turbo-booster in making that transition from idea to implementation.

I still operate on both sides of this line, I produce designs for one team to implement in Figma, and have to answer their questions to give specific answers about all the details that a static image can’t cover. In my experience humility and agility are key in the design role.

I also create React components based on the work of designers in another team and manage a dev team that produces components in a design system. We have to deal with all the technical aspects of packaging up a library of reusable widgets, and maintaining them. I believe Organization and communication skills are key in the engineering management role.

Weeknotes 5

Tim Bendt — Sat, 23 Mar 2019 18:15:00 +0000

Liquid syntax error: Unknown tag 'endraw'

Weeknotes #4

Tim Bendt — Thu, 14 Mar 2019 18:15:00 +0000

Monday

Hmm… guess I missed last week. Stress sunk it’s claws into me.

Sore back. I’m feeling so old. Did some babysitting. Grateful for a big blessing on our family.

Cleaned up inboxes and task lists.

Tuesday

Business development and networking.

Created a “hire-me” page which required further integration of the CMS on systematicui.com as well as creating a twitter card.

Wednesday

Can’t stop reading about inv.tech. What a fascinating company, so completely transparent.

Completely trapped by over a foot of snow. Winter is still here.

Thursday

So, I built an interesting script for generating a Nuxt website from a static HTML file. It’s not that hard but it is interesting. Nuxt will lose any static payload data once it’s done with hydration, assuming that you will make an API call after hydration. That’s a bit of a pain, so you have to write your dynamic generation-time data into a JSON file and then embed it in your output JS with webpack require() assignment.

Friday

🌞🌤❄️🌬☔️cool emoji weather library parses text and picks an emoji.

Started watching https://www.invisionapp.com/design-system-manager/expert-advice/heartache-design-scale

I ordered contacts with an app. Pretty neat experience, but it’s still amazing how often multi-step forms lose state or experience similar bugs.

https://blog.prototypr.io/what-do-you-need-to-know-before-starting-a-design-system-448158acc084

https://medium.com/invisible-reports/why-report-in-public-d4b94306a52f

Weeknotes #3

Tim Bendt — Sat, 02 Mar 2019 18:15:00 +0000

Over the Weekend I spent quite a bit of time on a side project that could turn into a really interesting service. It’s a tool that’s useful for deploying and testing CSS design systems. Puppeteer + Docker + Node + Typescript + Mongo Stitch. Super exciting.

Monday

Played with my boys in the morning, enjoyed the sun and watched a small avalanche on the mountain nearby.

I’ve been writing docs, and came up with 12 Factors for Enterprise-Level Front-End Code Quality

Linting
TypeScript
Unit Testing
E2E or Integration Testing
Git, PRs and Code reviews
Continuous Integration
Multiple Environments
Dependency Mgmt. & Security Auditing
Visual Regression Testing
Error Monitoring
Performance Monitoring
Documentation

Tuesday

Hey someone started on a new version of Fractal! It even has a Vue demo. 😍

I built a new project boilerplate for design system projects using Parcel for compilation, XO for Linting, even somehow managed to get TypeScript Support working.

Wednesday

Created a project generator script for design systems with different boilerplate options for folder structure and CSS preprocessors. https://github.com/sirtimbly/systematic-ui-scripts

Rebuilt a Nuxt 1.4 site in Nuxt 2.4. Figured out how to get ESLint working with that setup, and typescript again. What a pain. I never realized how easy TSLint was.

Thursday

Posted a new project on my portfolio. Designing a Perfect-fit Soluton for a Niche Industry

Friday

Re-discovered Astrum for design systems. Light weight design systems running on JS in the browser. No build step or dev server. Interesting.

Order some Darn Tough Socks they last a long time and when they do wear out you can get free replacements from the company.

Weeknotes #2

Tim Bendt — Thu, 21 Feb 2019 18:15:00 +0000

Monday

Fixed design bugs on timbly.com, more responsive, using tachyons.

Had to figure out how to tell if a slot is empty on a Vue component (TS class).

public get hasDefaultSlot() {
    return !!this.$slots.default;
}

It’s 2019 and CSS is awesome. But, we still can’t prevent orphan words when wrapping lines of text.

Have you tried Sublime Merge? I opened it again today – I like it, but I think I still prefer fork.

Tuesday

I’m using the AWS Amplify SDK, and it’s pretty decent. Fully featured authentication implementation. Their docs are nice, and they ship Vue and Reat UI components.

Wednesday

A super usefuly way to get basic SVG icons quickly

Thursday

Doing a lot of Git rebase from multiple developers.

Trying to get fontawesome-vue to actually do treeshaking… with limited success.

Friday

An article about running puppeteer automatically

A good starting place for automated chrome screenshots

Lot’s of time automating visual regressing tests.

Weeknotes #1

Tim Bendt — Sat, 16 Feb 2019 18:15:00 +0000

Saw this “Weeknotes” idea on some other blogs and decided it’s a good idea. For a while I was trying to write an article every week on dev.to – but I missed week 6 and now it’s hard to get back on the habit. Maybe if I’m adding some value to my personal blog again I can be a little more motivated to write.

Monday

Watched too much twitch. Apex Legends looks so awesome.

Set up perforance monitoring of an app through Calibre - It’s really excellent.

Looked at the latest version of UI Engine to see if it’s a good basis for my next design system. It can display plain HTML or handlebars templates like Fractal, but it also supports displaying Vue and React components, so that’s a pretty good option. Latest version has some great improvements in configuration also.

Tuesday

Found uptime robot. Good free plan. Found an interesting blog from Remy Sharp about rebuilding the very first web browser at CERN on the 30th anniversary of the web.

Wednesday

Lot’s of code reviews today. Hunting down the domain registrar for a client to see why their old website hosting dissappeared. Mystery. If it weren’t for the wayback machine we would lose a lot more websites due to neglect.

Thursday

Spent a lot of time building a initial prototype serverless+FRETS app on Zeit Now. Amazing stack. Will have to write more. It is totally possible to deploy serverless functions written in TypeScript without pre-compiling.

Friday

Discussed CSS and HTML with my mentee. Lots of basic rules like when to use position. The concepts of selector specificity, and background images. Saw a really weird thing happen when viewing a flex element on Chrome mobile viewport emulator. The whole flex item shrunk down to fit in the available flexbox space… interesting. Setting a pixel value on the flex item seemed to solve it.

Saw this article about UX and login forms from Brad Frost. Don’t Get Clever with Login Forms.

The Great Divide is Real, But You Get to Choose Your Side

Tim Bendt — Sun, 03 Feb 2019 00:26:33 +0000

Some articles recently have had an impact on me, and they are important for context in this debate that is boiling up in our industry. I recommend reading The Great Divide, HTML CSS and Our Vanishing Entry-Points, by Rachel Andrews - as well as HTML is a Compilation Target by Christian Heilmann.

I don't actually feel all that angry about the way CSS and HTML are being treated. I feel worried. And, as is normal, the worry is about identity and how I'm perceived by others. I'm worried that I am being foolish and short-sighted about web app development. And I'm worried that I'm not actually the kind of web designer that I thought I was.

And what is that identity I'm worried about maintaining? I started as the guy who does HTML and CSS cutup of photoshop files. I worked at a small agency with one other designer and several "programmers". We built hundreds of websites for small businesses. I had been making websites for myself and other since 1999, but when I graduated from college and started a "career" I really grew into an expert with CSS and all the little browser quirks and tricks that needed to be discovered the hard way.

I convinced the other people in my team to move from table layouts to pure CSS around 2006. Floats, man. Floats... Shudder

I had taken computer science classes in college along side all the design and communication classes, but it wasn't really something I loved. I thought of myself as a designer first, but I was expected to turn my photoshop designs into real flexible web page templates that could handle any content that a CMS might put into them. And doing that design work in a browser was a lot of fun for me. The mysterious alchemy of server side programming was still a little bit beyond what I was comfortable with, despite a few forays into PHP during college. Eventually, I began scripting interactions inside Flash widgets and "Rich Internet Applications". I was able to take that knowledge and begin applying that to javascript in the browser. And around that time jQuery came out and made everything so much better.

Due to some weird career shifts I found myself as a developer on an enterprise backend web development team in 2010. I found myself learning new skills rapidly, backend programming with C# and ASP.Net MVC, database design, architecture diagrams, big enterprise software development lifecycle procedures.

What I've discovered over the past 20 years is that really what I wanted all along was to build awesome experiences that were easy to build and easy to share. HTML and CSS were never "the easy entry point", they were the weird technical fiddly syntax that you needed to learn to manipulate to get the desired output on the screen. Learning to be a programmer was something that had to happen organically as I needed it. Now that I've been diving deep into coding javascript applications for the last 5 years, and writing backend server apps for 9 years, I can say that I don't care to treat HTML and CSS as anything particularly "precious". They are just the structured data formats that are needed to tell the browser how to render the UI. If we have layers of tools that can create all the necessary HTML and CSS dynamically from javascript, then it doesn't really matter to me. We can still make that app accessible, we can still make it performant, we can still open it up in developer tools and view all the DOM nodes and style properties.

I don't think writing all your CSS in JS is a good idea. I think we can still build useful and reusable CSS that takes advantage of the cascade, instead of fearing it. We can deal with the nature of global scope through understanding instead of just overwriting everything with a random ID to create isolation. CSS was built as it is for a reason, it's worthwhile to know the why's and understand how to use those aspects. But, that doesn't mean it's always wrong to subvert the usual expectations of how CSS works. Atomic CSS is a great example of this.

I've always held onto an identity as a frontend developer, even while I was focusing on design, or server-side development. And now that my own vision of frontend developer fits more closely with the larger view of the flood of newer JS engineers that build single page apps and bypass HTML and CSS when it's convenient, I wonder if I'm being short-sighted and irresponsible with my craft. I care about treating the web responsibly with a long-term perspective on our work being usable for dozens of years. If we build a content website with a JS toolchain we need to make sure it's outputting static HTML pages that are enhanced by JS when it's loaded - like Nuxt does.

I ended up in a place where I think the modern toolchains and SPA development frameworks are really exiting and useful. I know more than I ever expected to know about the event loop, the call stack, virtual-dom, and functional code. And it was my choice to pursue learning what I did. I have privilege and luck and a great deal of enthusiasm to help me arrive at the side of the divide where I am. I can tell you it's not a great divide anymore, It's just exciting to look out across a rich and varied landscape of web development approaches and think back fondly on the peaks that I've stood upon in the past and look ahead to the foggy future where more exiting climbs await me.

You Could be Building a Web app Without Writing any New HTML or CSS code. 😳 🤯

Tim Bendt — Thu, 24 Jan 2019 00:02:47 +0000

I have been writing a lot of web apps for a long time. Over the past year or so I've been slowly developing a functional JavaScript library for browser-based-apps. I was inspired by the wide variety of virtual-dom based libraries, and the concepts of functional reactive programming. Specifically there is a pattern that captured my imagination called SAM.

SAM stands for State Action Model. And it's a way of constructing your app that works really well with simple vanilla JS. I wanted to write something using this pattern but with the additional help of TypeScript.

I like the idea of building something from first principles to understand what's really going on. So I started looking into how these libraries like React, Vue, Preact, and Mithril work. I discovered that you don't have to use JSX or a template compiler, you can just write hyperscript functions to render your UI. I found a lightweight standalone virtualdom implemented in TypeScript and started wrapping some helpers around it to make the SAM pattern easy to follow.

Thus was born FRETS.

https://github.com/sirtimbly/frets#readme

If you want to see what a FRETS app looks like in action then check out this little Demo. It demonstrates the basic functionality of navigation, validation, and async updates.

Take a look at the code in the frets-starter app to see how it's all pieced together. UI Components are pure functions. They simply return a bunch of VNodes (Virtual Dom Nodes) for the virtual-dom rendering layer to use for diffing. Functions are superior to objects and template strings because they are easy to compose and refactor. (Especially with TypeScript).

The user interface is a pure function with no side-effects because it is only responsible for expressing the contents of the modelProps object, which is frozen and marked as Readonly for strictness whenever a developer is expected to interact with it. This is one area where Typescript can really help prevent deep modification and accidental side-effects.

Atomic CSS transformed into JS

When you see how these UI rendering methods are written you'll notice they don't look like normal hyperscript functions.

  import { $, $$ } from "./base-styles.ts";

  export const grayBox = (childNodes) => $.div.p2.m1.border.rounded.bgLightyGray.h(childNodes);

Instead of passing the tag name and class names as strings, I created a tool that analyzes any CSS file and generates a typescript file full of chainable helper methods to generate hyperscript functions that can only implement a strict set of classes. This approach perfectly fits the atomic CSS libraries that provide a huge collection of classes that apply exactly one visual CSS property. I like using Tachyons or it's lighter ancestor Bass CSS. The api is fluent, every time you hit '.' you get auto-completion listing all the available CSS properties to add. And when you're done chainging Atomic CSS classes you call the .h() method and pass in the properties and childnodes like you would with any other hyperscript function.

So the end result of this is that you're not writing anything that looks like HTML syntax or CSS syntax for your app. You're just writing functions that create HTML in the Dom and using developer friendly tools to help you find and use the CSS classes available to you for visual formatting. It's like an evolution of CSS in JS, but without the JS ever needing to parse or create CSS during runtime.

I like HTML and CSS. I've been building websites for almost 20 years now. I know CSS very well, and I do not hate it. I just think it's interesting to try something new, and as a developer I enjoy the way my IDE helps me write very functional and composable code without having to do any template interpretation.

State

The state in FRETS is a custom class that you pass into the FRETS constructor. Your UI will be a pure expression of this immutable object.

export class TodoListProps extends PropsWithFields {
  public name: string;
  public email: string;
  public todos: ITodo[];
  public complete: number;

  constructor() {
    // set some defaults
  }
}

Actions

Actions are what respond to user interactions and events. When someone clicks something or types into a field the state has to be updated. Actions are responsible for this. First you write an empty class to specify your action names.

export class TodoListActions extends ActionsWithFields {
  public saveName: (e: Event) => void;
  // and the rest with this same type signature
}

You have to then specify your concrete implementation on the FRETS object after it's been initialized.

const F = new FRETS<TodoListProps, TodoListActions>(new TodoListProps(), new TodoListActions());

F.actions.changeName = F.registerAction((e: Event, data: TodoListProps) => {
  data.name = (e.target as HTMLInputElement).value;
  // add action specific business logic here, but not validation
  // also you can add 3rd party API calls here
  return data;
});

Any actions that kick off an async function can call F.render() inside it's promise .then handler.

Model

The Model is responsible for handling, validating and calculating the proposed new properties that the "actions" return. This is done through two functions you specify on your app, validator and calculator.

// Register the state calculation function
F.calculator = (newProps: TodoListProps, oldProps: TodoListProps): TodoListProps => {
  // add your derived state business logic here
  const completedCount = newProps.todos.filter(t => (t.completed === true)).length;
  return {...newProps, completed: completedCount };
};

All changes to the UI that is displayed have to be based up the values that are finally returned from the "calculator" method. Which get stored on F.modelProps and are accessible from inside the UI rendering methods because they receive a reference to the App as an argument every time rendering occurs (automatically after any action is triggered).

All of this working together creates a predictable loop of logic that should be easy to reason about for a developer. You always know exactly where your business logic is: mutations are happening inside an action, and derived values are inside the calculator function. Rendering logic is always in the rendering functions, and you should be able to reason about how the UI got into the state it is at any point in the application's lifecycle.

There's a lot more about this in the API docs. And some more friendly docs are coming soon. Thanks!