You could find the āļø š Online version here. Or buy it here which I recommend you should. I remind authorās introduction.
Tao of React is for beginners who want to advance further in their knowledge. The best time to read it is when youāve grasped the fundamentals and are starting to build real applications.
You should read this after couple months to a year of using react. It wonāt bring more value to the fresher, but when familar with react, the book will help you advance your react code. I donāt mean all the things in this book are the best practices. The author just gave some recommendations for each topic, and including the pros and cons, or reasoning on which is good in which case. Besides, the book also focus on organizing code, balancing testing - things I belive are the key differences between senior and junior mindset. The book are easy to read and adapt, even with a backend dev like me.
I just note some take away to make the longer š for a full experience, you should try it yourself.
Until some anti-patterns come. Iām not sure if these anti-patterns are traditional approaches, or are they fit to the context. But trying to make run leads me to some funny experiments and allowed me understand absinthe, dataloader better. Letās move on.
Consider schemas. Normally, we have product has_one profile, and vs profile belongs_to product.
But in my graph, External depends on Products and Products should know nothing about External, even the module name. Every business functions will be kept on External.
defmodule Products.Product do
schema "products" do
# Lots of fields
# has_one(:external_profile, External.Profile)
end
end
defmodule External.Profile do
alias Products.Product
schema "external_profiles" do
belongs_to(:product, Product)
end
end
Thing went well, until exposing to graphql, I had 2 options, creating a root query for profile, or making it a productās field - which is obviously, clearer and lesser work. But without has_one - thereās no magic powder to let absinthe know how to load it. So I had to make my own magic powder. It was the point I unveiled the not-so-magic of dataloader.
def dataloader() do
fn parent, _args, %{context: %{loader: loader}} ->
product_id =
case parent do
%Product{id: product_id} -> product_id
%{product_id: product_id} -> product_id
_ -> nil
end
loader
|> Dataloader.load(__MODULE__, {:one, __MODULE__}, product_id: product_id)
|> on_load(fn loader ->
{
:ok,
Dataloader.get(loader, __MODULE__, {:one, __MODULE__}, product_id: product_id)
}
end)
end
end
In the end, itās just 2 parts: loading and getting. The most important here is the way we extract the key to load and get. In this case, the product_id from profile. Without has_one, we must define it ourself.
The same approach when I once tried to load list of participants from list of participant id.
defmodule Order do
schema "orders" do
# ...
field :participants, {:array, Ecto.UUID}
end
end
Having a link table is overkill this case. We only need to show and filter the order by participants sometimes. Before, I returned list of id, then client make another query to get list of participants. Filtering is even easier with array of uuid, no joining, just a nested query. To eliminate the 2nd query from client, I applied the custom dataloader. Similar to case above, replace load/get by load_many/get_many in this case, and the way we get the keys - participant_ids.
def dataloader() do
fn parent, _args, %{context: %{loader: loader}} ->
participant_ids =
case parent do
%{participants: ids} -> ids
_ -> []
end
loader
|> Dataloader.load_many(:default, Participant, participant_ids)
|> on_load(fn loader ->
participants = Dataloader.get_many(loader, :default, Participant, participant_ids)
{:ok, participants}
end)
end
end
By this, order.participants is list of participants. The code on frontend is simple now, and I could remove the participants query in the root.
To make a conclusion, I believe itās fun to write custom dataloader. But as an anti-pattern, too many custom dataloader will cause you headache. When looking back the first case, I still regret that a single has_one relation could save lots of custom code š.
Revise some goal setting related
Why do we set goals? Why do we need to follow up?
Having goals is a good way to focus attention on the things that are important. It allows us to create a vision of how we would like our life to be. When we have a goal, we tend to increase the amount of time and effort we spend on an activity, and develop effective strategies to achieve that goal.
[WIP] Answer why on each goal.
Some questions to concern:
Remember: Thereās no right or wrong, chose which is helpful.
Get started with your focus area, look back last incompleted goals. Some questions need to answer:
When I took over the Deliany project, one of the immediate challenges was how it exposed almost all data to GraphQL. Nearly every Ecto schema had a corresponding GraphQL type. While this isnāt a dealbreaker for small projects, it becomes a maintenance nightmare as the application grows across multiple layers.
Consider a books table in PostgreSQL: we have a Book Ecto schema, which leads to a BookType in Absinthe. Absinthe then generates a type Book in schema.graphql, which is passed to the frontend to generate a TypeScript type Book. To make matters worse, tools like the Apollo GraphQL generator often produce many Maybe<Type> fieldsāwhich is reasonable but often too loose for strict application logic. This often forces us to generate yet another validated type, like SafeBook, with stricter typing for forms and displays. I felt there was significant duplication in storing and syncing schemas across Absinthe, the backend SDL, frontend types, and TypeScript, often requiring custom CI scripts to keep them in sync.
Another issue is the volume of data. Exposing everything might speed up development initially, especially with a frontend-heavy team, but pushing too much business logic to the frontend risks data leaks, wastes network traffic, and leads to stale data. Reorganizing these types, auditing their usage, and moving logic back to the backend is high-impact work that optimizes both the application and the workflow.
During this reorganization, I noticed that even harmless changesālike moving or renaming filesācaused massive, noisy diffs in the schema.graphql file. This happens because Absinthe renders the SDL based on the order in which types are encountered. I wanted the generated schema to be deterministic and resistant to these structural changes. While Absinthe doesnāt support sorted output out of the box, the good news is that it allows for custom rendering. The rendering logic is quite straightforward, as seen in the Absinthe source code. To make the schema easier to diff, we can sort types and fields by their names before rendering.
defp render(%Blueprint{} = bp, _) do
# ...
all_type_definitions =
type_definitions
|> Enum.reject(&(&1.__struct__ == Blueprint.Schema.SchemaDeclaration))
|> Enum.sort_by(fn
%{name: "RootQueryType"} ->
"0"
%{name: "RootMutationType"} ->
"1"
%{name: "RootSubscriptionType"} ->
"2"
%Absinthe.Blueprint.Schema.ScalarTypeDefinition{name: name} ->
"3#{Absinthe.Blueprint.Schema.ScalarTypeDefinition}-#{name}"
%Absinthe.Blueprint.Schema.EnumTypeDefinition{name: name} ->
"4#{Absinthe.Blueprint.Schema.EnumTypeDefinition}-#{name}"
%m{name: name} ->
"#{m}-#{name}"
end)
# ...
end
Iāve shared my full version here: Utils.Absinthe.Schema.Notation.SDL.MyRender.
How do we tell Absinthe to use this custom renderer? We need to create a custom Mix task to generate the schema.graphql file. You can follow the pattern of the standard Absinthe SDL task but swap in the custom renderer:
def generate_schema(%Options{schema: schema}) do
# ...
case Absinthe.Pipeline.run(schema.__absinthe_blueprint__(), pipeline) do
{:ok, blueprint, _phases} ->
{:ok,
Utils.Absinthe.Schema.Notation.SDL.MyRender.inspect(blueprint, %{pretty: true})}
_ ->
{:error, "Failed to render schema"}
end
end
While some features like deterministic SDL sorting seem obvious but are missing from the Absinthe core, the library is flexible enough to be patched for your specific needs. Iām generally not a fan of maintaining custom patches, but compared to the pain of managing noisy diffs across multiple 4,000-line GraphQL schemas, this small customization is a price well worth paying.
]]>// both sentry.client.config.js and sentry.server.config.ts
import * as Sentry from '@sentry/nextjs';
if (process.env.NEXT_PUBLIC_SENTRY_DSN) {
Sentry.init({
release: `project-name@${process.env.NEXT_PUBLIC_VERSION}`,
enabled: true,
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
environment: process.env.NEXT_PUBLIC_SENTRY_ENV,
});
}
// next.config.js
const { withSentryConfig } = require('@sentry/nextjs');
// ...
sentry: {
disableClientWebpackPlugin: true,
disableServerWebpackPlugin: true,
},
// ...
module.exports = withSentryConfig(nextConfig);
Itās cool, but useless. Yes, for error on node server, it may acceptable. But errors on client browsers are nearly useless. Without source map, minified stacktrace in error report like a forest. I have to admit that I never find out to fix any bug by guessing root cause from those minified source code.
Besides, weāre using apollojs, which mean all the fetching from server will be shown as fetch POST https://backend.com/api/graphql [200] 21:07:17 š„²
We lived with it for years, until I was getting mad of tons of Sentry report which broken our package, but had no clues of what are they, how to fix them. After hour of googling and dive in Sentry documentation with tries, surprisingly, we was only one step away from the finish line. I dont get into detail on how do I tested them out, just all the config here to save future-me one day.
// both sentry.client.config.js and sentry.server.config.ts
import * as Sentry from '@sentry/nextjs';
import { excludeGraphQLFetch } from 'apollo-link-sentry';
const SENTRY_DSN: string = process.env.NEXT_PUBLIC_SENTRY_DSN;
if (SENTRY_DSN) {
Sentry.init({
release: `project@${process.env.NEXT_PUBLIC_VERSION}`,
enabled: true,
dsn: SENTRY_DSN,
environment: process.env.NEXT_PUBLIC_SENTRY_ENV,
ignoreErrors: [
'Validation failed',
"Can't find variable: zaloJSV2",
],
tracesSampleRate:
process.env.NEXT_PUBLIC_SENTRY_ENV === 'production' ? 0.15 : 0,
allowUrls: [/https?:\/\/backend.com/],
beforeBreadcrumb: excludeGraphQLFetch,
});
}
// next.config.js
const { withSentryConfig } = require('@sentry/nextjs');
// ... nextConfig
sentry: {
hideSourceMaps: true,
widenClientFileUpload: true,
disableServerWebpackPlugin: true,
},
// ...
const sentryWebpackPluginOptions = {
org: 'org',
project: 'project',
authToken: process.env.SENTRY_AUTH_TOKEN,
silent: false, // Enable to debug when build and upload artifact
release: `project@${process.env.NEXT_PUBLIC_VERSION}`,
};
module.exports = withSentryConfig(nextConfig, sentryWebpackPluginOptions);
// apollo client
return new ApolloClient({
link: ApolloLink.from([
new SentryLink({
setTransaction: false,
setFingerprint: false,
attachBreadcrumbs: { includeError: true },
]),
// ...
Some take away:
release in Sentry.init must be the sames with in sentryWebpackPluginOptions, or youāll find 2 tracked versions on Sentry.sentryWebpackPluginOptions silent is useful when checking if source map is generated and pushed?When processing in batch, I get a lot cases just remove the invalid item in list. Like this.
estimations
|> Enum.filter(fn
%{"total_price" => _} -> true
_ -> false
end)
In the beginning, it was just fine. But after I wrote the 10th block like this, it annoyed me. Most of case, the filter function feed to Enum.filter/1 always the same, the only different part is a pattern, why donāt we just define a function filter_by_pattern(pattern)? Just return true or false :3 if matched.
Itās turn out I was late, Iām not the one think about it. Other languages support pattern matching use a match function, why donāt elixir - a modern-pure-pattern-mattching-based language support match function?
https://hexdocs.pm/elixir/1.14/Kernel.html#match?/2
Supported from early versions, so we could write shorter.
estimations
|> Enum.filter(&match?(%{"total_price" => _}, &1))
match?/2 to check match or not, which fit exactly to Enum.filer/1SELECT DISTINCT
date_trunc('minute', "when") AS minute
, count(*) OVER (ORDER BY date_trunc('minute', "when")) AS running_ct
FROM mytable
ORDER BY 1;
Ref date_part
SELECT date_part('year', "inserted_at") FROM users
CREATE EXTENSION IF NOT EXISTS btree_gist;
ALTER TABLE promotions
ADD CONSTRAINT overlapping_running_time
EXCLUDE USING gist (
product_id WITH =,
tsrange("start_at", "end_at", '[)') WITH &&
) WHERE ("status" = 'active');
|> exclusion_constraint(:start_at,
name: :overlapping_running_time,
message: "Discount of product #{product_id} is overlapped"
)
šØ Only superuser role has permission to CREATE EXTENSION.
Or Production grade release
Sometimes, when render chart, to have new color for new item, I usually use average from items around. i.e. between red bar and green bar, I used the average transition color #7f7f00 (127,127,0) bar. You could see, #ff0000 #7f7f00 #00ff00 itās weird, seems a bit darker than expected.
Use another lighter color: #b4b400 (180,180,0) in this case.
#ff0000#b4b400#00ff00
#ff0000#7f7f00#00ff00
How do we have the number 180/0xb4:
r' = SQRT(r0^2 + r1^2) = SQRT((255^2) + (0^2)) = 180 = 0xb4
There are 2 factors of this problem.
First is the way our human eyes preceive the brightness. Itās not straight, but in a roughly logarithmic scale. Technically, rgb(0,0,0) has 0 brightness, or 0 photons; rgb(1,1,1) - full brightness - has 100% photons. But rgb(0.5, 0.5, 0.5) has only 22% photons - 22% brightness. Even worse, rgb(0.25, 0.25, 0.25) has only 5% photons, not 25% brightness as our expected. The average doesnāt apply here.
Second, the way CCD sensor records a pixel in computer. Itās pure number. Moreover, it stores square root of the brightness, to save storage. By this, dark color datapoints - near 0 - are recorded more than bright color datapoints - near 1. This roughly imitate human vision. Then square back when display.
But, when we want to modify, remember, the rgb numbers we work on are square root, we must square back before take any action.
]]>