janwirth

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

~~Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.~~

More info

Should be work with 0.18

Destructuring(or pattern matching) is a way used to extract data from a data structure(tuple, list, record) that mirros the construction. Compare to other languages, Elm support much less destructuring but let's see what it got !

Tuple

myTuple = ("A", "B", "C")
myNestedTuple = ("A", "B", "C", ("X", "Y", "Z"))

Building a Maintainable, Agile Architecture for Realtime, Transactional Apps

A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.

With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.

We use GraphQL to dyn

The State of Container Queries

tl;dr Developers would like the idea to style components based on a parent's width rather than depend solely on the viewport media query. This would allow modular components to style themselves while being agnostic to the viewport.

There is currently a lot of developer interest in getting a feature like Container Queries (née "Element Queryies") shipped in a browser.

2-min Catchup

Here are official'ish documents to outline the developer community's desires.

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

	business - The Business associated with this Page. Visible only with a page access token or a user access token that has admin rights on the page

	can_checkin - Whether this page has checkin functionality enabled - bool

	can_post - Whether the current session user can post on this Page - bool

	category - The Page's category. e.g. Product/Service, Computers/Technology - string

	category_list - The Page's sub-categories - list<pagecategory>

	import random
	import time
	import numpy
	from exceptions import ValueError


	class PushID(object):
	# Modeled after base64 web-safe chars, but ordered by ASCII.
	PUSH_CHARS = ('-0123456789'
	'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

	/**
	* Fancy ID generator that creates 20-character string identifiers with the following properties:
	*
	* 1. They're based on timestamp so that they sort after any existing ids.
	* 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs.
	* 3. They sort lexicographically (so the timestamp is converted to characters that will sort properly).
	* 4. They're monotonically increasing. Even if you generate more than one in the same timestamp, the
	* latter ones will sort after the former ones. We do this by using the previous random bits
	* but "incrementing" them by 1 (only in the case of a timestamp collision).
	*/