Alle (designere) bør lese mer faglitteratur og diskutere relevansen av det vi leser med de vi jobber med! Hvordan komme i gang? Jeg har samlet noen tips!

Aller først, hvorfor bør vi lese mer? Kunnskapen som er nedskrevet i bøker er akkumulert kunnskap som forfatteren gjerne har brukt flere år på å tilegne seg, reflektere over og formidle. Ved å lese kan vi ta del i denne kunnskapen, få nye impulser, perspektiver og metoder som beriker vår egen måte å jobbe og tenke på. 

Verdien av å lese blir i tillegg langt større når vi diskuterer bokens relevans med kollegaer og teammedlemmer. Da tvinges vi til å gjenfortelle, reflektere og mene noe om det vi leser. Det kan for eksempel være nyttig å spørre seg «Hvordan er dette relevant for det jeg jobber med?», «Er jeg enig eller uenig i det jeg leser?», «Ble noen av mine tidligere antakelser eller oppfatninger utfordret, hvordan?». Det å dvele ved det vi leser og teste det ut i vår hverdag gjør at vi husker vi bedre, og får en dypere forståelse for bokens innhold.


Noen tips for for å lese mer faglitteratur:

Finn din motivasjon for å lese mer – Hva ønsker du å lære eller få ut av lesingen?

Ha en aktiv leseliste – bøker du gleder deg til å lese

Planlegg lesningen til din peaktime – Tiden på døgnet når du er mest våken og oppmerksom

«Timebox» lesingen – Les fortere enn normalt over kortere tid med maksimalt fokus.

Ta notater – det du ønsker å huske eller ting du lurer på

Gjenfortell og diskuter det du leser – da husker du bedre og det kan skape gode diskusjoner



Dette er et drypp fra faggruppen Leseinitiativet UX 📚 Håper du blir inspirert til å lese en fagbok i julen og starte det nye året med spennende faglige diskusjoner om noe nytt du har lært! 🎄

Tips for å lese mer faglitteratur!

Code splitting and lazy loading can be synonymous with heartache and headache. Luckily, smart people have made tools to make it easier for us. Webpack and React Router are familiar to many in the React community. Add loadable-components to the mix, and you have all the ingredients for code splitting and lazy loading without the tears!

The state of React apps ⚛️⏳

Many React apps started life as Single Page Applications (SPAs), especially in the before-times, when the recommended way to get started with React was to scaffold your app with create-react-app or to do it yourself with a custom Webpack config. Since then, the community has largely eschewed SPAs and Client Side Rendering (CSR) for Serverside Rendering (SSR) and Multipage-like Apps. Remix and Next.js beeing at the forefront of this change in opinion has brought several benefits to those projects that can successfully build (or indeed have been rebuilt) on those technologies, amongst them efficent code splitting and lazy loading of the components and pages the app consists of.

One of the biggest pains of working with traditional SPAs, wether client or server rendered, is that every new feature, each new page and component, any logic you add or CSS you fiddle with, will invariably be bundled into the same massive JavaScript and CSS bundle, growing fatter and fatter every time you deploy. This is fine at first, when your app has just a handful of pages, but as your business and app grows, you'll eventually find yourself shipping several megabytes of JavaScript and CSS to every visitor to your website.

This hurts. A lot. Not just your users, but your business and the planet as well. Large bundles mean long load times. Long load times frustrates your users, and lead to higher bounce rates. Bad performance also hurts your SEO rankings, as Google downranks pages that score badly on Core Web Vitals metrics. Finally, the large bundle sizes also hurt the planet. Every megabyte transferred on the wire caues on average 0,32g of CO2 emissions. Though that might not sound like much, it adds up quickly. If your site ships a just a megabyte of data and attracts more than 3000 visitors per day, you'll cause a kilogram of CO2 emissions per day. In a month, ~30 kg. In a year, ~360 kg.

So what's a poor developer to do? Well, luckily for you, and indeed all of us, you most likely already have the tools you need to deal with this, easily and without tears.

Webpack magic 🧙‍♂️✨

Webpack is an amazing piece of tech, despite provoking the ire of many developers struggling to configure it correctly. Luckily, code splitting with Webpack isn't something you need to configure your tears out over. Getting started with code splitting is as easy as replacing this:

With this:

This is a dynamic import, a part of the ECMAScript standard. Instead of importing the module synchronusly, we import it asynchronusly. Webpack will see our dynamic import, and since we can await its load (i.e. Webpack can determine that we don't need it immediately when the script starts) Webpack will automatically split it out in its own module when compiling. Whats more, the module won't actually be downloaded until the import call is made. Like magic!

Code splitting and lazy loading in React 🔪💤🧑‍💻

"That's great and all, but how do I make use of it in my React app?" you may ask at this point. And it's a fair point. Using bare dynamic imports doesn't help you much when what we're trying to code split is React Components. For this, the React team has you covered, with React.lazy. This will wrap your dynamic import, and provide a suspendable component for you to render in your app. So, instead of doing this:

You would write this:

Et voila! Our component is code split thanks to the dynamic import, and lazily loaded thanks to the lazy component definition. This will work for any default exported component in your app! Webpack creates a separate bundle for the component file, and React automatically handles downloading the component bundle at the appropriate time when the component is rendered. The Suspense fallback will be rendered while the component loads.

Lift it up to the routes 🆙🧭

This is where the real magic happens. Most medium or large React apps use some type of routing library for rendering based on the current browser URL. It is therefore often sensible to start splitting your app at the route level, splitting each route into its own bundle. Let us for this example assume that you are using React Router. Then a minimal setup could look like this:

This will leave you with at least three bundles: One for each of the two pages, and one so called critical bundle that will be downloaded for all pages. The critical bundle is the bundle that all pages of your app needs to load in order to function. In this case, that would be the bundle containing the App component, since all other routes are a child of it.

Now, why "at least three components"? As we mentioned before, Webpack is a pretty clever piece of technology. Say we have multiple routes, and several shared components imported into  some, but not all of the pages. It would be inefficient to duplicate these components between the bundles that use them, or to include them in the critical bundle when not all bundles need them. Webpack will pick up on this, and will automatically split those shared components out into their own bundles! Whats more, Webpack will also do this for any libraries that are shared across dynamically imported modules. Pure magic!

What this means, is that just introducing lazily loaded and dynamically imported routes in your application will not just code split your routes, but your components and NPM libraries as well. This can give a drastic reduction in the size of the critical bundle, cutting it in half with just route level splitting.

SSR, loadable-components and React Router 6 🤔

The examples so far use the built in React.lazy for code splitting. Whilst that should work just fine with most CSR apps, you may want to consider using loadable-components if you are doing SSR. Its API is quite similar to React.lazy, but does not need Suspense. With the example from before:

Notice that the API is more or less identical, but doesn't need the Suspense wrapper. Suspense works with SSR in React 18 using one of the new streaming rendering methods, but does not work with older versions of React. That makes loadable-components your only option if you are doing SSR in React 17 or older.

Additionally, loadable-components has some extra bells and whistles for SSR, allowing us to extract prefetch and preload tags to put in the HTML head, speeding up page load by loading these resources immediately as the browser receives the HTML from the server.

If you are using React Router 6, you may have noticed that they now allow a lazy prop on routes, making those lazy loaded. That can also work well, but doesn't have a facility for preloading the neccesary bundles for each page. You'll want a way to split individual components anyway, making loadable-components a good bet here too.

If you end up using loadable-components with React Router 6, you can benefit from tweaking the loaders for those components a bit. Say you define your routes like this, in an array:

Doing it this way will cause a blank page to render during navigation, while loadable-component is downloading the page component. That is a less than ideal user experience, but can be solved by adjusting the route definition a bit. Recall that route navigation in React Router 6 will suspend until any loaders on the next route complete. Also, loadable-components exposes a method to initiate and await the load of a component. We can use this to ensure that the next route is completely loaded before navigation happens, like so:

Here, we have simply wrapped each loader call in a function that returns the component to React Router, as well as a loader that will call and await the component load. No more white flashes, no more loading spinners!

Get your scissors ready! ✂️👯

As we have seen, code splitting and lazy loading a React app need not be a tearful affair. In fact, it can be quite fun chasing an ever smaller bundle size! This blog post is just scratching the surface of what can become a rather deep rabbit hole, should you dig deep enough. I speak from experience, having code split a large SSR-driven React app down to less than a third of its original size. So, armed with the scissor that is code splitting in React, go forth and split your app into a thousand tiny pieces. Speed up your website, improve your SEO ranking, and save the world a bit with every page load.

Happy code splitting!

Break your app into pieces: Code splitting and lazy loading without the tears

Don't you just hate how boring ls is? I mean, it just spits out the names of files and folders on a line, one after the other. Come on, it's not 1987 anymore.
Let's try to make our own version, using Rust! Don't know any Rust? Go ahead and read last year's Introduction to Rust first! 🦀 I'll be waiting 🥱

Let's list some files


To get started, let's just grab all the files in our current working directory and spit them back out. Let's use the excellent walkdir-crate. Let's create our project and get going, and call our project explore 🔎



And in our src/main.rs:


And run it:


Wow, that's a lot of output! It prints all build files and .git-files, but I truncated it. Let's clean that up by changing the files we're interested in, which means hiding hidden files (e.g. files that start with .) and only show one-level of depth:


Now let's run it again:


Nice! 🎉

Oh, and by the way, I'm skipping showing you all the imports, so if you're following along, just use rust-analyzer's code actions to import them automatically.


Hold for the applause 👏


Let's add the excellent command-line argument parsing library Clap and use that to parse some input arguments. We want it to figure out the parsing, so we add the feature derive as well:


To use Clap, we create a struct representing our input arguments, slap on some attributes to tell Clap how to initialize things, and change our usages so it works just the same:


And run it again to check it still works as before:


It does! And now we can also tweak the output with --max-depth, --min-depth, --hidden and --path/-p!


Awesome!

Sizable files


Now let's spice things up by adding size output to our entries! Let's look at an entry's metadata and find out:


Looks simple enough, but that printing stuff is weird. Let's break it down: {size} will print the size variable, which is in bytes. {size:>9} means to align the number right-aligned to 9 characters in width. \t adds a tab character, which aligns the next stuff somewhat nicely. And also we add a B because the size is in bytes. Let's run it:



Sweeeet! Now we're almost on par with ls.However, at some point in time, or perhaps from the beginning, ls got support for colors. We can't be any worse! Let's add some colors to differentiate directories, files and symlinks from each other. colored looks good!


And in our src/main.rs main loop:




colored adds a Colorize-trait which gives us extension methods like .blue() and friends, but it only works on strings (&str and String), so we need to convert the output of .display() to a string, using .to_string(). If you'd inspect .display(), you would see it returns a Display-type, which implements std::fmt::Display, which is why it works without converting it to a string first. But anyway, let's run it:


Sweeeeeet!! Ehh... wait.. You can't really see the colors like that.. Give me a second... Now!


Woo! It's looking a bit bland with the size missing colors, so let's spice it with some colors too:


And rerun:


Awesome! However, this beautiful new colored output highlights a problem. 9471B? It's over 9000! We should get ahead of ourselves and format large byte quantities into something more readable. Let's add bytesize and use it!


bytesize adds B, KB or whatever, so we need to remove our B from the output. Also, since we want the formatting 123 KB first, and then color it, we need to format it using format!("{}", ByteSize(size)) and then color it green, and then print it:


Rerun time:



Nice!

Putting aside the noise


Now, I don't know about you, but I'm not a super fan about it spitting out ./ as a prefix to everything, and the whole directory path for every line of the nested files.


To fix this, let's grab only the filename and extension without all the prefixing paths to each entry before printing. To avoid printing everything on a single line and not understanding which file belongs in which directory, let's indent each file by the depth it has (the number of nested directories it is in). Also, as a bonus, walkdir gives us the directory itself as a single entry first, so we automatically understand which entry belongs to which directory! Let's make it clearer by putting it into code. Let's change our main loop code for formatting entries to:


And let's compile and run, again:


Awesome! I love the dimmed bars for indentation, too. Nice touch, Isak. 😏

Time for a change


This is a pretty nice-looking CLI-tool already! Let's spice it up to ls's level by adding some date stuff. Rust has support for dates in the standard library, but doesn't support formatting them (trust me, with the amount of weird stuff going on with dates/timestamps and the stability promises of a standard library, this is really a good thing).
Let's use chrono:


We saw earlier that each entry has a .metadata() object. It returns an Option<Metadata> and we've been .unwrap()-ping it without problem until now. This object also contains a .modified()-method that gives us a Result of a SystemTime. We've been cowboying fine so far, so let's unwrap that as well and hope it exists:


Let's add an option for actually printing the date modified, because we might not always need it. In our Options-struct, add:


Onto formatting and actually using chrono. For non-serialization formats, it's pretty nice to see which day, date and time something has changed. I don't know what you like, but my favorite RFC for those types of date formats is RFC 2822, which spits out something in the likes of Mon, 13 Nov 2023 19:18:49 +0000, so we'll just use chrono to spit out that!


Let's create a formatted_date variable that checks if the modified/-m-flag is set, and returns an empty string if it isn't. If it is, it will convert our date to chrono's DateTime<Utc>, spit out the beautiful RFC 2822 output, and then strip away the ugly + 0000-suffix, because who wants that.




We'll print out our dates in blue:


Sick! 🤩


Now let's not compare ourselves with others...


I'm not gonna lie, this is pretty similar to the output of the awesome tool exa, also written in Rust. Let's compare them!


In fact, ignoring the permissions and author of the files (because who cares about those), they're mostly the same! Except our outputs files with hidden files and directories last. This is a simple fix:


And rerun one last time!


Neeat 😎

This article is probably getting a bit too long, so let's leave it at that. Adding more features such as permissions, error-handling and so on is left as an exercise to the reader (but really can be solved by running cargo add anyhow, search-and-replacing .unwrap() with .context("describe the error")? to yeet the error out of the function, assuming you changed the main function's return type to anyhow::Result<()> and return Ok(()) at the end of the function). Huh, we almost could have done all that stuff in the parenthesis, but anyhow.


Time to feed the dog


If you want to use this program as a replacement for ls, it's super easy!
Just run:


And then a bunch of output is spat out. Afterwards it should be installed in $HOME/.cargo/bin/explore ore wherever your Cargo installation is, and assuming you have that in your path (which you should have), you can run it like this now!

Conclusion


Thanks for reading! I hope you see how easy it is to create a tool of your own using Rust and its great tooling and ecosystem. And we did all of this in... how many lines? Well, the title was a lie, we actually only used 68 lines of Rust, according to the awesome written-in-Rust tool tokei


68 lines for all that functionality! And of course some more when we include the dependencies, but oh well. Pretty nice! Doesn't make for a good title, though... Perhaps "A better ls in less than 69 lines of Rust" is nicer. Is it really a better version of ls? Probably not, but that wouldn't make for a good title either.


There's plenty more that can be done if you want to create your own version. As an example, you can add:

Permissions

Author

Date created

Options for all of the above

Support for ignoring files and folders according to ignore-files (perhaps use ignore)- And so on


Happy holidays! 🦀


4-Dec

Today's posts

Tips for å lese mer faglitteratur!

Break your app into pieces: Code splitting and lazy loading without the tears

A better `ls` in 100 lines of Rust