thenewdynamic / huge Goto Github PK

This: https://github.com/theNewDynamic/huge/discussions/6

We'll just use the latest when we push to Alpha I think.

Currently Huge looks for declared scripts and styles (through config) and parse each entry into a processable object.
Then when user uses `partial "huge/styles/tags" (slice "main" "carousel"), it go look for the pre-parsed entries.

This means #46 is not possible to implement because when will try and overwrite or pass its script/style config directly from partial context, we won't parse its settings.

We should:

Parse the assets when used through the partial:

{{ partial "huge/scripts/tags" (slice
   "main"
   (dict
      "name" "carousel"
      "params" (partial "func/GetSlides")
   )
) }}

We'll be able to range on the slice,

1. look for a declared script call main from the config and parse it.
2. look for a declared script called carousel, merge this other keys on top of it and parse it.

Will address #46

Some results from --templateMetrics don't add up... Then again this report is not always 100% reliable, but count usually is, and some partials are invoked more than they should it seems. Especially on the scripts/styles packages.

In the event that an image whose filename contains whitespaces but is invoked (with resources.Get) using %20, Hugo (or Huge) fails to publish it.

For example this file is stored at /uploads/that image needs space.jpg

Might be upstream, or not... hence the need to investigate.

The current solution implemented for a project is to replace the %20 before invoking:

{{ $destination := replace .Destination "%20" " " }}
{{ $image := partial "huge/media/Get" $destination }}

This usually triggers some issues (competing with users' local fonts).

I wonder what is the value of using a local value in 2022.

Currently the data of each transformed asset is built alongside the list of assets in GetSelectedStyles, we should have a stand alone function for this so that GetSelectedStyles runs it on each element.

This will allow to structure the data outside of GetSelectedStyles.

This should help with #22

Currently it's impossible to easily overwrite the default swap display.

Also this has been imported from the former style module and deserve a bit of modernizing.

For now the user cannot get the data related to a processed resource.

Parameters

A string, would only return the data for one style identified by either its name or path.

A slice, would return an array of maps listing the data for the styles identified.

Examples

{{ with partial "huge/scripts/Get" "carousel" }}
  {{ $carouselJSPermalink := .Permalink }}
{{ end }}

This would look for any env.yaml file mounted under assets and fallback on this if getenv is not successful.

I recently decided to switch to using internal when using

• <style></style> instead of <link href=> and
• <script></script> instead of <script src>

This makes much more sense than inline which could be interpreted for styles as applying the style on the tags <p style="color:blue;"> and also is the official term for those two ways of loading script/stypes.

This will look exactly as the base starter but built with tailwind. This will be the opportunity to let user play right out of the box with tailwind and postcss.

For some reason when Huge is add to the project, the live server stops working.

Any time a change is made on a template file (not assets, not data, not returning partials), even though the change is aknowledged in the terminal, the rebuild never happens.

There is no error or unusual message, not even with --verbose

On AGNI this has been addressed with --poll 700ms which is another way of watching files (checking every 700ms) rather on save.

This would allow to define the Front Matter key to be used to interpret the SEO image of any given project.

We currently have an undocumented feature (from tnd-scripts port) explained here: https://github.com/theNewDynamic/hugo-module-tnd-scripts#env_keys

We should

1. Add it to the documentation
2. Make sure it uses env/GetVar so user can use the HUGE's local env variable logic

We should try it with many many files. I know one publication project whose files we could use to stress test Huge...

Our form module is really neat but could benefit from some refactoring. Using the default provider is super easy, but customizing some aspect of the code for using a custom provider can be cumbersome. Plus it's a very old plugin.

The core logic would be the same, but the way every bits of HTML can be overridden by the project's own would be simplified.

Integrating to Huge would make sure former projects are not impacted, and new ones can use the new code as part of Huge.

Currently HUGE/SEO assumes some keys should be used for SEO tags, like image, images etc.. We should allow user to set their own key for images and others through configuration

#_huge/config/seo
mapping:
   featured: image

Currently huge/env/When takes a string ex: production and only returns true and the current environment matches that string or string is always.

It should accept a slice of strings.

{{ if partial "huge/env/When" (slice "production" "staging") }}
do it
{{ end }}

Currently the user has no say in the default attributes we add to any <script> tag.

<script 
        src="https://..."
        type="text/javascript"
        crossorigin="anonymous" 
        defer="defer"
 </style>

1. We should investigate if these constitutes good defaults
2. We should allow user to overwrite these with configuration and add any custom attributes they see fit. Some libraries requires custom attributes. Iubenda and similar services as well etc...

No npm packages. The simplest thing à la Astro starter.

We should create a helper core feature to invoke some in-house useful functions:

FormatPath.html
GetLocalizedValue.html
GetPage.html
GetPageResource.html
GetTranslations.html
IsExternalURL.html
IsProduction.html
Merge.html
PartialExists.html
ReverseSlice.html
SliceSplit.html

Initial idea was to build #18 but we should probably surface this as a public feature and setup test for huge ourselves.

The concept is, for every partial that the user wants to test they will have to create its homonymous testing partial

func/GetFeaturedImage.html < the partial
func/GetFeaturedImage__test.html < the test partial.

The test partial will return a list of tests each having an input and and an output. The latter will be compared to the partial returned value.

W'll then have one or more public huge function which returns a list of the tests along with a name and a test value (true or false).

Example:

partials/func/GetFeaturedImage.html

{{ $image := "/no-image.jpg" }}
{{ with .Params.featured_image }}
  {{ $image = . }}
{{ end }}
{{ return $image}}

The following test partials will return an array of tests.
partials/func/GetFeaturedImage__test.html

{{ return slice
  (dict
    "name" "homepage"
    "input" site.Home
    "output" "/from_home.jpg"
  )
  (dict
    "name" "about page"
    "input" (site.GetPage "/about")
    "output" "/no-image.jpg"
  )
}}

Usage

User can use one or more functions which would perform the tests and return a "list" of logs for each tests.

We could have huge/tests/GetFails for example to only list the failing test or huge/tests/GetAll etc... This would return a list of arrays with the name of the name of the partial, the name of the test etc...

- partial func/GetFeaturedImage.html
  name: homepage
  success true
- partial func/GetFeaturedImage.html 
  name: about page
  success true

Currently this little beauty is only available locally (one file) whereas Huge spreads its configuration into multiple files.

huge/config/Get "scripts" will process the data found in _huge/config/scripts.yaml.
Thus anchors from _huge/config/styles.yaml will not be found.

One big file.

We should look for all the files, concatenate all of their content into one big string (making sure each file's content is stored under a key matching its filename`.

scripts: (scripts.yaml content)
styles: (styles.yaml content)
# ...

This way we'll process every config files as one and users will be able to use anchors across files.

Currently on huge_sandbox (and AGNI), this line of code which looks for ...() config functions prevents the site from rebuilding on save.

Need to investigage.

Currently as we are using the assets directory to interpret user configuration, there is no way for a them or another module to declare its own assets (_huge/config/scripts or _huge/config/styes) as those files will ultimately be overwritten by the project's own.

Solution 1

Allow style and scripts config to be passed directly on partial invocations:

{{/* Scripts */}}
{{ $scripts := slice
  (dict
    "path" "js/index.js"
    "integrity" "true"
  )
  (dict
    "path" "js/carousel.js"
    "integrity" "true"
    "params" $theme_config.carousel.slides
  )
}}
{{ partial "huge/scripts/tags" $scripts }}

Solution 2

Cook up a merging/appending solution for the lists of and general config.

This could be simply prepending using a naming convention reserving _huge/config/scripts.yaml to the user while modules and themes use _huge/config/scripts_ananke

In each case, I think Solution 1 could benefit any user.

User might not want to systematically delate a config file like _huge/config/seo.yaml to return to default settings. So they'll probably just delete a lone key/value pair in there and move on.

Currently an empty configuration file breaks the build.

We should try and make HUGE ignore empty config file without breaking the build.

Currently huge/env/GetVar fails silently which might be interesting one an environment variable's value is false. But if not set at all, huge should produce a warning.

Pending this is addressed upstream, we might take a 👀 at https://www.brycewray.com/posts/2021/11/making-tailwind-jit-work-hugo/ and see...

That would not be helpful with type but would at least ease up presentation of complex data.

This could be a yaml output using:

{{ $yaml := . | transform.Remarshal "yaml" }}
{{ highlight $yaml "yaml" "" }}

Something like:

If the -e flag is set Hugo will use it as "environment" even if HUGO_ENV is also set so:

This is not good as we often use the -e flag to simply use a different set of settings for the CI (netlify or cloudflare) but HUGO_ENV should always have precedence.

After the fix:

Currently we only preload woff2files. But we should only allow users to limit preload on certain declarations. If a font's bold italic variant is not used above the fold, it will be useless and careless to preload it.

I think by default we should preload everything (according to the preload When setting) and allow user to overwrite for each declaration with preload: false.

Currently user cannot retrieve the SEO data from a page easily. This could also help improve the overrides logic

Parameters

A page

{{ with partial "huge/seo/Get" $ }}
{{ end }}

Currently the way we ensure every files is published (even if not accessed by Hugo) is to range given directories and use the .RelPermalink method on them. We could use the undocumented but more elegant .Publish method.

Currently while SEO is promoted has being a zero configuration feature, it requires jsonld: true for the jsonld functionality to be printed... I guess this should on by default.

Until #44 is completely resolved, we'll need users to opt in for it.

We'll add a global.yaml huge config file to enable_configuration_functions: true.

We should have a decent sandbox to try out new features and experiments Hugo upgrade.

The one I setup long ago is too simplistic and outdated.

We should probably limit the preload on one format, so that the browser does not download what it does not need.

Just like we can easily pass params to the scripts which can be imported from the js code,

we could try and add the same for styles. Those could be inserted as css variables:

styles:
-  path: main.scss
    params:
      env: huge/env/Get()
      darkMode: true

Which would generate something like:

:root {
  --env: production;
  --darkMode: true;
}

I'm thinking it would be better to give control to user over the positioning of those variable declaration, shall it overwrite some of their own...

Maybe it could create a file which could then be imported by user mimicking the JS side of this...

Which means we'll probably need a testing project in the repo. Much like Hugo themes loads an example project themselves.

It's fairly simple to try and detect go template syntax (just looking for this: {{) in _huge/config/*.yaml file if found, use .ExecuteAsTemplate.

Usage

This would allow users to do something like:

# _huge/config/seo.yaml
enable_follow: true
default_image: {{ site.Home.Params.featured_image }}

# _huge/config/seo.yaml
disable_jsonld: true
default_image: {{ partial "func/GetDefaultImage" "GetDefaultImage" }}

Limitation

• It could only work with basic types (string, boolean, integer) as maps or slice would require first converting them to yaml/json etc... Can be trivial for json, but yaml needs proper indenting etc...
• It could not bear a dynamic context. But if a context is really needed user could use a partial:

default_image: {{ partial "func/GetDefaultImage" (site.GetPage "/blog") }}

Re-using UX and logic of https://github.com/theNewDynamic/hugo-module-tnd-socials

We should use the same terminology of other HUGE features

• Declaring a service, and then invoking it.

With the new resources.Copy method, it is now always possible to rename a resources (image or otherwise).

We should exploit the tranformations array to add one more possible transformation: 'rename'

Currently user rely on registed scrips and name list their names in the tags partial context.

We should be able to

1. Directly add an unregistered style/script by simply passing its settings as a map in the slice.
2. Merge the map passed in the slice with the registered settings (if name from the map is found as a declared script/style)

Currently we only look for image, images, we could add featured, featured_image and more...

Now to avoid having to write a with/else for each tested keys, I'd rather wait for golang/go#20531 (comment) which will introduce a break statement in Go Template loops!

{{ range slice "image" "featured_image" "featured" }}
  {{ with index .Params . }}
    {{ $img = . }}
    {{ break }}
  {{ end }}
{{ end }}