Prepare website for domain substitution #135
Loading…
Reference in New Issue
No description provided.
Delete Branch "esavkin/web2019:134-intl-domain"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR prepares the website and shop for #134:
Substitution happens in JS runtime in following events:
Also added preprocessor parameters for testing locally.
This way the mirror can directly pull the HTML or this repo and serve it.
2742826bc4to85f30cc269Client-side in JS, seriously? Can't you just set an environment variable to be read by Zola?
Can you do it without "replacement"? I can't believe the code is still such a mess.
@ -0,0 +1,8 @@import React from "react";import {DEFAULT_DOMAIN, INTL_DOMAIN, USE_INTL_DOMAIN} from "./utils";We need three variables instead of one because?
@ -95,0 +100,4 @@export const USE_INTL_DOMAIN = true;// #!elseexport const USE_INTL_DOMAIN = window.location.hostname === INTL_DOMAIN;// #!endifNix/Hydra can simply create one .js file that defines
DOMAIN = "xxxx"and replace all this nonsense.So many problems created by your laziness and resistance to advice.
@ -1,6 +1,7 @@const shop_data = {API_RFQ: 'https://hooks.m-labs.hk/rfq',INTL_API_RFQ: 'https://m-labs-intl.com/api/rfq',Just define SHOP_API_RFQ in a generated config.js together with DOMAIN.
@ -10,6 +10,7 @@ import {TriggerCrateWarnings, TriggerWarnings} from "./warnings";import {Validation, validateEmail, validateNote, validateJSONInput} from "./validate";import {CratesToJSON, JSONToCrates} from "./json_porter";import {ProcessOptionsToData} from "./options/Options";import {RFQMessages} from "./RFQMessages";Is it really necessary to split the messages into this other file?
Well, the loader is the same for both JS and JSX, and it works fine if you move RFQMessages object into shop_store and import React, but pure JS files do not permit JSX (unless you import react) and it would be quite unexpected for developers to see JSX code in JS file.
Also, the shop_store.js is already quite big and better be split in future.
So both reasons are styling and best practices thing.
A few-lines file with a couple strings is not good style and not best practice.
And it does not help with the size of shop_store.js either.
It's not a couple of strings - it's a JSX code, one of the fields of which contains an actual link
mailto:. If it was just a string-only solution, it would appear in the page as<a href="....">email</a>, or without mailto links, which makes it less convenient.Also since we substitute domains, it is better to use some unified method of doing it, i.e. utilize
DomainedEmailcomponent, that's why I added a link in this message.I'll merge
RFQMessagesintoDomainedEmail, though it is not exactly good for component hierarchy.Cannot just access window.DOMAIN here, as you do in JS in other places?
Of course it can, just I don't want to populate external variables in the code.
Then I don't see what the problem is. Splitting some random "RFQ" strings into Domained.jsx does not make any sense to me.
I'm now not sure what do you want from this. If you want it to remain in shop_store, then I explained earlier why it is not suitable here.
What's the issue if you access window.DOMAIN in shop_store.js and keep the strings there?
For what purpose?
With this PR the email in RFQ error case becomes clickable, which is an usability improvement.
These "strings" are JSX elements now, i.e. rendered as HTML, and not as a text. If they would remain strings, the clickable email wouldn't be possible, because it would be rendered as text (i.e. user would see the html itself).
Since normally JS doesn't contain JSX elements, it would be a weird practice to make shop_store.js depend on React to add such elements. Also, I introduced shop_store.js in earlier refactoring to keep data/logic away from rendering as much as possible, which is a standard practice. So putting the "strings" (actually elements) back to shop_store would be a regress.
Also spreading dependencies on external variables across code is not a good practice either. I admit it is not in ideal state right now, but it was far worse before.
Of course it is possible to make something like template string and leave the email unclickable, but it is a regress relative to this PR in usability and in code quality relative to before this PR.
@ -49,0 +55,4 @@window.DOMAIN = 'm-labs.hk';window.API_RFQ = `https://hooks.${window.DOMAIN}/rfq`;{% endif %}</script>Just define a hooks.m-labs-intl.com instead of this nonsense.
@ -49,0 +49,4 @@<script>{% if "m-labs-intl.com" == get_env(name="DOMAINNAME", default="m-labs.hk") %}window.DOMAIN = 'm-labs-intl.com';window.DOMAIN = get_env(name="DOMAINNAME", default="m-labs.hk")?@ -27,2 +27,3 @@ENV: process.env.NODE_ENV,disable_card_highlight: falsedisable_card_highlight: false,intl_domain: false??????
33c7936e72toe06ce29220@ -16,3 +16,3 @@```zola serveDOMAINNAME=m-labs.hk zola serveJust make it a default?
It's default, but updated docs for less confusion.
Just say you can set the DOMAINNAME environment variable to something else. It doesn't need to feature prominently.
@ -11,3 +11,4 @@ highlight_code = true[extra]author = "M-Labs"domain = "m-labs.hk"What is this for?
e06ce29220to1ff79878be@ -0,0 +1 @@<a href="mailto:{{address}}@{{get_env(name="DOMAINNAME", default="m-labs.hk")}}">{{address}}@{{get_env(name="DOMAINNAME", default="m-labs.hk")}}</a>What is that?
Template to generate email link, obviously
Considering your constant rate of mistakes I better double-check instead of assuming it's "obvious". So this is what gets called when you use
{{ email(address="sb") }}?Yes
Ok. This is fine then.
Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.