I just uploaded a document with a lot of articles and some documentaries that I collected over the years. A lot on the Soviet Union, China and North Korea, but also more general stuff. Not sure which of this would be relevant for you, but feel free to copy anything you want.

https://0xacab.org/snippets/802

Because of new features like tagging, citations, search, etc., the UI will have to change significantly. I'd like to keep the site functional without JS on the client side, so any major additions to the UI need to degrade gracefully. Dropping this requirement because it'll be painful.

last test

It would be good to go through all the current tags and remove noise and synonyms, and move the tag alias work to happen in search rather than at DB load. The goal here is that if someone clicks dprk they also get results tagged juche, or if they search for cops they'll see also results tagged police, for example.

This will need a pipeline, maybe Docker build, server set up somewhere, DNS, etc.

Is this a feature request or a bug?

Feature

Expected behavior:

The pipeline shouldn't rebuild both the client and server and restart the server if it doesn't need to. Getting the diff from the previous tag can be used to only rebuild what's necessary, or just forever restart 0 if the only thing changed was db.yml. It would also be nice to only test on PRs, to avoid re-running tests on code we already know is good once it's merged and on npm version commits.

Actual behavior:

Everything is rebuilt and restarted on every tag.

Environment info (relevant browser, OS, etc.; run npx envinfo):

N/A

one

asdf

According to a Lighthouse report from today, the service worker doesn't seem to be working correctly. This could've been from the Workbox webpack plugin update.

https://example.com
example
tags: example, one, two

Description

It would be nice to be able to go to ?search=foo or ?tags=foo,bar and have that render the correct thing.

Related: #48, #43.

Additional context if applicable

The app is mostly static right now, so it would be a good time to think about changing to SSR. This would require flattening the directory structure (which would be a good thing anyway IMO).

Related: #20, #22.

We should enable http2 for clients that support it.

This is just a quirk of working with client-side routing, but can be fixed. Since /about is the only client-side route besides the home page right now, it's not a big deal.

As part of #5 we should have a submission form for new resources that hits GH to create a new issue or PR.

This should get hooked up to Codecov and Codeclimate, plus run tests on PRs and report back. Badges would be nice, too.

There are lots of wrappers cluttering up both the component structure and the actual DOM. This screenshot is one resource item. Two or three of the divs here could probably be refactored out.

I'm just running this the old-fashioned way, running Node on a VPS behind Nginx, but it might be nice to include a Docker build example and possibly Kubernetes deployments.

Related: #6

asdf

Is this a feature request or a bug?

Bug

Expected behavior:

Cloning the repository and running jekyll serve should produce a locally hosted site identical to https://marxist.space

Actual behavior:

Cloning and running jekyll serve renders a sitemap at the index, and pages that don't have the default layout (and therefore no CSS) applied to them. Furthermore, jekyll complains about the {% seo %} on line 5 of the default layout.

We could add structured data for better performance and appearance in search engine results. Some examples of things we could do:

• https://developers.google.com/search/docs/data-types/sitelinks-searchbox
• https://developers.google.com/search/docs/data-types/factcheck
• https://developers.google.com/search/docs/data-types/article

The first one would require rethinking search (see #43) to use a query string.

Validation can be done with http://linter.structured-data.org/ and https://search.google.com/structured-data/testing-tool, and should also be tested with https://www.webpagetest.org/lighthouse once it's deployed.

@aeshthetic's idea, we should satisfy the use case of "I need resources to help me explain that there are no death camps in Xinjiang," preferably with some kind of excerpts for easy citation. This probably depends on #8 but builds on top of it.

The current tag searching just checks for s on the end, which is crappy. There are libraries out there that singularize or pluralize words, we could use one of those instead.

On mobile widths, the tags and search are just pushed to the bottom with a jump button. This feels awkward.

It might be better to hide the tags and search completely on mobile, and have a button that toggles open a full-screen overlay that shows just the search and tags.

We'll need some kind of data storage. It'd be nice to avoid a database and keep flat files (JSON, YAML, or TOML) in the repo so folks can still contribute easily.

Description

Since everything except the actual resource list lives in a sidebar, it's getting a little long now. Collapsible sections should be added, so users can see only tags, only search, etc.

Additional context if applicable

There is currently only one example client test. There's a Jest + Enzyme setup ready, and most of the components can be tested pretty simply with snapshots. It would be nice to have reasonably good coverage.

The submit/clear search buttons are a little ugly right now. Some nice SVGs that fit well with the look and feel of the site would go a long way towards making things feel more uniform.

Is this a feature request or a bug?

Bug

Expected behavior:

Coverage should probably be in the single digits

Actual behavior:

Coverage on the client is reporting as being 100% because it's only including tested files

Environment info (relevant browser, OS, etc.; run npx envinfo):

This should happen before v2, to explain what we're doing and why.

asdf

The tags list, especially, is all bad when running locally, but is fine in a prod build. I don't know why yet, and it could even be just me.

There's currently only one example server test. Jest setup is ready for them, it would be cool to have moderately good coverage.

asdf

Is this a feature request or a bug?

Bug

Expected behavior:

If I search for china debunk I should see only resources that match both of those

Actual behavior:

I see resources that match any of those

The fix is probably to add matchAllTokens: true to the options here

Environment info (relevant browser, OS, etc.; run npx envinfo):

N/A

Description

react-dev-utils has some nice helpers, but no independent changelog from CRA so it's hard to update without breaking everything. We should just remove it.

Additional context if applicable

Is this a feature request or a bug?

Bug

Expected behavior:

Search should work like a form, with a submit button.

Actual behavior:

Search is a debounced onchange right now. I thought this would be nice, but it feels really bad on mobile, and as the data set grows it's going to get slower and slower. This component should work more like a form.

Environment info (relevant browser, OS, etc.; run npx envinfo):

asdf

Is this a feature request or a bug?

Feature

Expected behavior:

The home page should only render X amount of items (maybe 50?), and load more on scroll.

Actual behavior:

Everything in the "database" is rendered on load. This isn't a huge problem right now, but as the data grows it might become one.

I've used a few different lazy loading components and haven't really loved any of them, but it might be better now with IntersectionObserver as long as there's a good polyfill out there.

This work would probably take place in here.

For v2 we'll need to move to actually running a server. Probably just use http://github.com/zacanger/ts-microservice-boilerplate as the base, since I know it already.

The current search works fine given the amount of data, but as that grows it'll get pretty nasty. It could be replaced with Fuse or something similar.

one

v2 will need a way to make content sortable and searchable. I think a system of set tags would be the best option here, so you could search for documentaries and china and get a list of items tagged with both, for example.

The React app should be profiled and improved. Removing Redux, removing Styled Components, and switching to a lighter-weight React alternative (Preact or Inferno) could all be helpful.

Things change at different sizes. It would be a good idea to pick one width as the "mobile" breakpoint to switch from a mobile/tablet experience to a desktop experience.

asdf

There are some issues according to lighthouse: https://www.webpagetest.org/result/200223_32_4e5df7c1793b17cb5a89d512b5630db5/

All of them should be easy to fix