Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APIs, Tags, and Adapters #78

Closed
jimafisk opened this issue Oct 26, 2020 · 1 comment
Closed

APIs, Tags, and Adapters #78

jimafisk opened this issue Oct 26, 2020 · 1 comment
Labels
documentation Improvements or additions to documentation question Further information is requested

Comments

@jimafisk
Copy link
Member

jimafisk commented Oct 26, 2020

Received some great questions from SKRY Online:

I have just watched your presentation on youtube https://www.youtube.com/watch?v=mPA_60o0Bek regarding Plenti and I found it to be a promising piece of technology. It seem it is similar Hugo in many ways, but with Svelte as templatng engine. I have also learned that you are JAMStacking, just like me. For that, I do use Sapper though, and Sapper, unfortunately, doesn't export 100% pre-rendered pages. I believe that the future is in JAMStack since it fast and secure by design. And Plenti is the right tool for it.

I see it the same way, I'm big on JAMstack as well :). I had the rough concept for Plenti when I started the JAMstack Boston meetup but I delayed starting for a couple of years because I thought someone would naturally build exactly what I wanted. The timeline ultimately worked out though because Plenti used React for a brief period of time before I converted it over to Svelte. We're definitely getting inspiration from projects like Hugo and NetlifyCMS, but also trying to rethink some of the fundamental concepts of how a static site generator should work. Mainly questions like, could the data source have a completely flexible and simplified structure so you don't need an API where you have look up reserved key words, could the frontend use a modern component based approach that is reactive and still builds extremely fast and consistently, and is there an opportunity to actually tie aspects more tightly together (like a CMS) to limit options and make the developer's life easier. JAMstack in general takes a very "decoupled" approach, which is great in so many ways, but my theory is there are huge advantages in JAMstack in general that can be taken advantage of by more people if some of the setup was streamlined.

Maybe you can direct me to two of the following:

  1. How to fetch and prebuild pages with the data from a rest API or graphQL

This is something that still needs some work to be more integrated. We have an open ticket for external APIs so check that out if want to stay posted on progress, or if you want to drop some thoughts over there. In the meantime what you could do is write your own helpers (in JavaScript or whatever) to pull from third party services and have it simply write JSON to the content/<your_type>/ folder, but I realize that's not ideal long-term.

  1. How to create #tags that will allow jumping to dynamic lists of posts(types) with the same tags. Other than that, I am definitely taking it for a spin, since Sapper soon will be outdated, and @svelte/next(sveltekit) is not ready yet.

The cool thing about types in Plenti is that their structure is completely up to you. You could create a type called "blogs" that is used for individual blog posts, or you could create a type called "main_menu" that you use as links in a navbar but don't actually have any endpoints for (hint: pass the --endpoint=false flag to plenti new type command). It's a little strange to wrap your head around at first, but you could create a type called "tags" (plenti new type tags) and use that to tie together content, such as blog posts. I just made an example repo to demonstrate what this would look like: https://github.com/jimafisk/plenti-tags-example. Just let me know if you have any questions on that (probably makes sense to just open issues related to that over there: https://github.com/jimafisk/plenti-tags-example/issues/new).

And just curious, do you plan to have some kind of adapter for upcoming Svelte 4 like '@sveltejs/adapter-go' or '@sveltejs/adapter-plenti'

That's an interesting concept. Just to make sure I understand correctly, this would be an NPM package that you would pull into Svelte to do Plenti builds - kind of the reverse of what we're doing now (pulling Svelte into Plenti)? I hadn't thought about this at all, but I'm open to it, especially if someone who knows more about it than myself wants to contribute. I'm not sure how challenging that will be given the Go backend of Plenti but it sounds cool. Thanks for putting it on my radar!

@jimafisk jimafisk added question Further information is requested documentation Improvements or additions to documentation labels Oct 26, 2020
@jimafisk
Copy link
Member Author

If anyone got to the tags repo above before this comment, my apologies. I had a global gitignore for folders called "tags" because I used to use ctags with vim: https://stackoverflow.com/questions/26654808/is-tags-a-reserved-keyword-in-git. The repo should be updated now, so hopefully it works. Just let me know if it gives you any trouble. Thanks!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant