gaearon

Next.js client-only SPA example

Made this example to show how to use Next.js router for a 100% SPA (no JS server) app.

You use Next.js router like normally, but don't define getStaticProps and such. Instead you do client-only fetching with swr, react-query, or similar methods.

You can generate HTML fallback for the page if there's something meaningful to show before you "know" the params. (Remember, HTML is static, so it can't respond to dynamic query. But it can be different per route.)

Don't like Next? Here's how to do the same in Gatsby.

kevin-smets

Default

Powerlevel10k

IsaacXen

WWDC                                      2007  2008  2009
2010 2011 2012 2013 2014 2015 

yogthos

Introductory resources

• High level overview https://yogthos.github.io/ClojureDistilled.html
• An Animated Introduction to Clojure https://markm208.github.io/cljbook/
• Interactive tutorial in a browser https://tryclojure.org/
• Interactive exercises http://clojurescriptkoans.com/
• Clerk notebooks with introductory examples https://github.clerk.garden/anthonygalea/notes-on-clojure
• More interactive exercises https://4clojure.oxal.org/
• Lambda Island tutorials https://lambdaisland.com/
• Functional Programming with Clojure resources https://practicalli.github.io/

CristinaSolana

1. Clone your fork:

git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git

2. Add remote from original repository in your forked repository:

cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream

tclementdev

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

• You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

• Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse