reuters-graphics / bluprint_graphics-kit Goto Github PK

On pre-commit, check file sizes in project-files and statics and prompt a confirmation before committing them with a warning. If user responds with YES this file is meant to be here, we'll add it to gitignore and update the index.

Maybe this is a graphics-bin CLI...

A commit caused SvelteKit to fail to build: ea99515

Most of our staff use Google docs to write body text and import that into their project as JSON.

If we can always do that, we can use a proper internationalisation lib like svelte-i18n to handle translation.

That should make it much easier to translate for clients and Gdansk and more powerful if we want to start making different translations accessible for dotcom. It also means I can rip out the logic for the 3 other ways we handle translatable text from the existing rig.

Open question how we handle translation in ai2html components, but because text is usually placed pixel-perfect in AI, I'm operating under the assumption we'd create different AI files for each translation we have.

... as documented for devs here, we're can't currently use d3 above 6.7.0 and also can't use the default namespace.

Creating this issue to track with others in SvelteKit and Vite until this is resolved.

vitejs/vite#2491

sveltejs/kit#1908

Is it really doing that much? Maybe better to just tell folks to use the sveltekit store...

For schema data, dateModified is pulled in from a key in package.json via the SEO component.

Need to check how/if that gets set automatically by the publisher scripts.

Also not sure what best practices are currently for including that as a timestamp, e.g., as part of the headline component.

Right now we're pinned to @sveltejs/kit@next.

Once they hit 1.0, we'll pin and close this issue.

CSV? Images? SVGs?

May move this to another repo like graphics-bin, but would like to add a CLI to install the ai2html script for SvelteKit.

... we need to decide what to do with.

• Check user profiles/creds
• Create GitHub repo in TR
• Push to GitHub on publish
• Google docs/sheets
• Image srcsets
• Trello card

Should we move this to a separate library for 1.0?

Update chart modules to d3 > 7.0 so we don't have to bundle both 6.0 and 7.0 in projects going forward?

... to resemble our house style.

Failing to automatically create a new TR GitHub repo for new project.
Prasanta is having the same issue. We checked for credentials in keychain and they seem to be there and correct. My key shouldn't be expired as I created it < 2 months ago.

Prototype the workflow for AI graphics in this rig.

Check this.

After talking to Chris a bit more, I can see how it's useful to have a global stylesheet for catch-all rules already pre-connected to the project. So like an equivalent main.scss already imported into the Page component.

I still think we want to actively encourage folks to write styles in their components so they're guaranteed to be scoped correctly, but seems like this will shortcut a bit of comprehension time for new folks.

cc:ing @MinamiFunakoshiTR and @fcage in case y'all feel differently.

Working out the alias paths for static files isn't exactly straightforward.

Would be good to obscure this behind a function...

Getting build errors from esbuild about .svelte being an unknown file type when building the page.

This is likely due to how we have configured the graphics-svelte-components library. Needs fixing and testing, but temporary fix may be to pin vite to 2.6.14.

One of the most flummoxing things for new folks are 500 errors Vite occasionally throws warning an element (usually anything using d3...) is not a valid SSR component.

SSR is still experimental in Vite and they're absolutely dealing with issues resolving dependencies, especially CJS ones.

If we turn off SSR in development only, then we don't get any more phantom 500s. Though we may then get more apps that don't build because someone is using window or something outside a lifecycle function.

Still, though, the relative frequency of using d3 vs. using non-Node compliant code probably tilts this in favour of disabling until Vite makes a few strides.

Should no longer be a root relative path.

Looking like it should be something like this now...

{
  kit: {
    appDir: '_app',
    paths: {
      assets:
        process.env.NODE_ENV === 'production'
          ? process.env.PREVIEW ? pkg.reuters.preview + 'cdn' : pkg.homepage + 'cdn'
          : '',
    },
  },
}

Probably this one: https://raw.githubusercontent.com/reuters-graphics/graphics.reuters.com/main/src/statics/img/home.jpg?token=AAVEY3Q3KBCBCIJTBZOYIG3AR7SDW

Because categorical chart module is now part of the boilerplate, I think we need to add d3-transition to package.json. Running yarn add d3-selection fixed the issue for me and i was able to create a preview

Just a summary thing about thinking in components and how to then layout your project lib directory.

Again, per chat with Chris, making a simple component with this structure:

lib/
  Chart/
    chart.js
    index.svelte

... which includes our boilerplate chart module class in chart.js, all plugged in in index.svelte ...

will help speed him up when starting new projects.

Consider adding a class onto an outer containing element -- article, maybe -- that represents the environment the page is built for. Something like: env-dev, env-rngs or env-aws.

This helps if you're writing SCSS rules -- especially w/ complex media queries -- that need different behaviour based on the environment.

This was originally pitched by @fcage while he was writing some relative paths in SCSS, but might have some other uses, too.

I tried manually adding a folder named oversize inside project-files but it's not being ignored. Do we want to add an empty oversize folder to the boilerplate and add it to gitignore?

On upload, a lot of our ai2svelte images are tripping over the 200kb warning you get. We should make those smaller.

...and specifically for internal contributions from the team.

Consider a PR template, e.g., SvelteKit's?

cf: #51 (comment)

Especially if Sam Granados and others who use ai a lot are going to use the new rig

Open question is whether this rig is going to shortcut creating Apple News versions of graphics.

Primary advantages of the new rig as proposed:

• We assume text comes in as JSON, likely from a Google Doc, (b/c we'll be using a proper internationalisation lib for translation), which we can enforce a standard structure on that could be repurposed for Apple News.
• Because we're component-izing graphic elements on the pages so we can cut them as separate embeds, does that make it easier to inline/embed them in Apple News spec?

What else would we need (that we could hopefully pull into a separate CLI, maybe??) to make this easier...

@swhart22 is going to investigate!

https://github.com/sveltejs/kit/tree/master/packages/adapter-static

Would need to package a _gfxpreview.{png|jpg} at the root of the interactive edition.

This will need thinking about where the business logic lives in relation to the publisher client.

Get a few of these:

22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-chart.svelte:54:0 Unused CSS selector "#g-ai-chart-box p"
22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-chart.svelte:58:0 Unused CSS selector "#g-ai-chart-box .g-aiAbs"
22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-chart.svelte:72:0 Unused CSS selector "#g-ai-chart-box .g-aiPointText p"
22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-scroller-1.svelte:78:0 Unused CSS selector "#g-step-1-box p"
22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-scroller-1.svelte:82:0 Unused CSS selector "#g-step-1-box .g-aiAbs"
22:00:48 [vite-plugin-svelte] /Users/jon/Scripts/bluprint_graphics-kit/src/lib/ai2svelte/ai-scroller-1.svelte:96:0 Unused CSS selector "#g-step-1-box .g-aiPointText p"

Should clean those warnings up in demo files so folks don't get warnings out-of-the-box.

All metadata for public pages should be handled with a custom component. Should work with the new publisher.

Also need some thought on the metadata we want for embeddables.

Will still link out to Svelte's docs on this, but can give a little bit of a Cliff's Notes on the concept for newbies.

this one

A quick digest of my own thoughts that other folks can add on wish-list-y stuff to...

Why a new rig?

The rig we have is great at producing a particular kind of project -- namely, one page and one embed -- but I think we need to anticipate a future where the structure of the projects we build is more flexible for us and for clients.

First, we want a rig that lets us create multi-page projects. App-like trackers or larger series should be able to be published in the same rig as a single page graphic. That also gives us the benefit of strong SEO on individual pages in tentpole projects like elections and our sports coverage. It also lets our staff scale up to work on more complex projects using the same tools they're already familiar with.

Once we solve multi-page we can also create a variable number of embeds, not just a one-to-one with the dotcom page. With that we're anticipating a world where we can build projects that consist solely of embeds that go into a CMS, e.g., arc, and start giving clients embeds that are more useful in their own CMSs.

We also need a rig that emphasises component-based patterns, so the same graphic can be pulled into different contexts, a page for dotcom and an embed for media to start. Once we get there we can start to develop components for repeated use that will unify our design (where we want it more standard) and significantly shortcut dev time.

I also want to start simplifying more of our building/publishing logic so our own rig tooling more closely aligns with build tools the wider community is working on. That will make it easier to translate our source code to clients who want to deeply customise our projects, easier to maintain our own infrastructure long-term and should get us some free stuff as the community builds smart additions to the frameworks we're using.

The tech that does it

File-based routing in "meta-frameworks" like Next.js and the new Sveltekit covers the most important feature we want: creating pages on the fly so we can split out the right number of pages and embeds for a project.

Sveltekit is in beta, but it has all the features we'd need already to build multi-page projects and split embeds for more flexibility for clients. To use it, we'd need to embrace Svelte as a team.

Several of the staff already have some level of familiarity with Svelte. Writing simple projects in it is much closer to the way staff currently write code compared to React, the only other viable option for us. It's also been well tested on projects from simple graphics to large elections apps and has wide support among newsnerds and devs, so we can be sure we won't dead-end in Yet Another JS Framework for a few years yet.

How we do it

We already have a working rig, so I think we build this one in parallel without creating any bottlenecks for the team. Once it's ready, we can bring staff online individually with projects that aren't especially deadline sensitive until we get a critical mass and can start to sunset the existing rig.

IE11 is into end-of-life, with support from Microsoft 365 dropping last year and most other mainstream support ending in 4 months. Global use is also under 1%.

If we drop it, we can start using JavaScript modules, which will significantly decrease the overhead for bundling and increase page speed.

Imagine a project that has a single page for graphics.reuters.com and two embeds published in two locales.

RNGS archives/editions

Here's a minimal example of the edition structure:

📁 public.zip
interactive/
  - index.html
  - embeds/
    - en/
      - chart/
        index.html
      - map/
        index.html
    - de/
      - chart/
        index.html
      - map/
        index.html

📁 media-en-chart.zip
media-interactive/
  - _gfxpreview.png
  - README.txt
  - host/
    - index.html

📁 media-en-map.zip
media-interactive/
  - _gfxpreview.png
  - README.txt
  - host/
    - index.html

📁 media-de-chart.zip
media-interactive/
  - _gfxpreview.png
  - README.txt
  - host/
    - index.html

📁 media-de-map.zip
media-interactive/
  - _gfxpreview.png
  - README.txt
  - host/
    - index.html

📁 media-code.zip
media-interactive/
  - _gfxpreview.png
  - app.zip
  - README.txt

public archive

All publicly hosted files go into a single archive, public.zip.

The archive only includes HTML documents. All page assets -- js, css, imgs -- are published to a separate CDN. That lets us absolutely reference them for easier self-hosting without needing to re-route relative src paths when the folder structure changes in the embeds.

media archives

📁 media-en-map.zip
media-interactive/
  - _gfxpreview.png
  - README.txt
  - host/
    - index.html

• _gfxpreview.png is a screen-grab of the embeddable graphic, generated during the publish process.
• README.txt includes the pym.js embed code referencing the page published in the public.zip/interactive archive.
• host/index.html is a duplication of the HTML document for the embed published in the public.zip/interactive archive.

code archive

📁 media-code.zip
media-interactive/
  - _gfxpreview.png
  - app.zip
  - README.txt

• _gfxpreview.png is the page's share card.
• app.zip is the git archive of the entire development project.
• README.txt includes instructions on how to start up the development server, customise src files and build a dist/ directory that can be uploaded to client's servers.

A commit caused SvelteKit to fail: refs/heads/master

Via husky hooks, eslint will now stop commits for errors like eqeqeq and no-unused-vars.

I think we should consider softening these and maybe a few others to warnings.

A commit caused SvelteKit to fail: f34d8f5

Not sure why but project-files is not being generated automatically when I start a new project. I checked package.json and .bluprintrc and the settings look right to me, though.

It's a good practice to have websites that pass W3C validation. Helps with cross-platform compliance, accessibility and SEO

Nice to have -

• Check and validate existing markup
• Add a validator in the workflow to show warnings and errors
• Make grammatically correct coding easier

Sample from one of our web pages built with sveltekit