so anything that boils down to the `@Page` / `@Get...
# framework-elide
s
so anything that boils down to the
@Page
/
@Get
annotations will work
d
does this mean we can't define new routes dynamically? I think it might be difficult to have the DSL define the routes statically
s
hm good question
wdym by dynamically? as in, IDs and other dynamic values in the URL?
or adding entire URLs in response to runtime conditions?
d
second one. the
page
block will be runtime - unless there is some interaction between
inline
and KSP we can take advantage of?
s
well the challenge there of course is the SSG nature of it
if we can compile the
page
block to JS and route client-side that's fine, in SSG mode
no problem there yeah
we'd just need to run the SSG engine against CSR mode which is no issue
you would just have to be okay with less code in the HTML and more in the JS bundle
d
actually nvm, we might not be talking about the same thing. I think it should be fine
s
in that case you'd just have
@Page("/")
and then we could do react routing which im currently integrating with
anyway its possible
toggling between CSR and SSR modes is essentially a one-line config change
Copy code
elide {
  server {
+    ssr {
+      enable()
+    }
  }
}
it's not an architectural difference
so that should at least mitigate any risk to this answer
d
yeah thats right. worst case we'd just handle with @Page("/") and do the route resolution independently
and it doesn't really matter because it's just going to be SSGd anyway
s
right, like that server controller only lives during the build
next handles this in an interesting way with
getStaticProps
i don't quite understand how it works yet but i plan to look into that too
if you, say, have a table of blog posts with
/post/:postId
, it should theoretically be able to fan-out to a set of HTML files with a
SELECT *
somewhere