Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Design an approach to isometric component support #16

Open
pimterry opened this issue May 11, 2016 · 4 comments
Open

Design an approach to isometric component support #16

pimterry opened this issue May 11, 2016 · 4 comments

Comments

@pimterry
Copy link
Owner

pimterry commented May 11, 2016

No description provided.

@gilbert
Copy link

gilbert commented Nov 1, 2016

How is progress on this? What are your main thoughts?

@pimterry
Copy link
Owner Author

pimterry commented Nov 1, 2016

Some progress! https://github.com/pimterry/leaflet-map-server-component is a fun isomorphic example, rendering on both sides.

It does that by extending server-components just there though, as a testing ground. I'm looking at porting various bits of this back into the core library in time, but not yet. Notable points:

  • I added an onServer property, so you can check components.onServer to switch logic for server and client (which is sadly required in a couple of places).
  • You need a server-components-for-web wrapper, to do the tiny bits of mapping to bring the APIs together (now maybe less necessary with Custom Elements v1 coming out), and to provide stubs for server-components-static (so that you can make sure you generate the same URLs for images and other resources on the client and server side).
  • Your browser-based dependencies might well not work out of the box. I found some nice tricks to wrap them so you can inject a DOM on demand (rather than them expecting one to exist globally), there's a blog post explaining it here: https://medium.com/@pimterry/building-a-server-rendered-map-component-part-2-using-client-side-libraries-6f1bb751f31c#.hkr80i601. This is a general server-side rendering problem that isn't specific to server-components or isometric rendering, but once you're building components complicated enough to need this, you're going to hit these problems.
  • You need to think about how module systems are going to work. This is a toy example, so I'm doing CommonJS server side and just browser global examples client-side, but if you want to use the same thing on both sides then life is going to get more complicated.

The resulting component code looks like this: https://github.com/pimterry/leaflet-map-server-component/blob/master/src/leaflet-map.js. It's mostly pretty good: there's a couple of lines that differ server vs client (search for .onServer), but otherwise the core logic all works nicely.

Hope that's useful! I'm still playing with these ideas and steadily iterating, and I'll be updating this to bring them to life a little more later on. Any feedback on what works for you though (or what doesn't) would be super helpful.

@gilbert
Copy link

gilbert commented Nov 1, 2016

Ahh, so you're running the full library server-side, pre-rendering what would have happened on an initial page load, and then sending that and everything else to the client. Very interesting; I had a similar idea, but this is one step further and a better fulfillment of what I had in mind :)

Do you have a vision for dependency + asset management? I can see server-components replacing tools like browserify/webpack since it could inspect the resulting HTML and potentially calculate the dependencies of all custom elements on the page.

@gilbert
Copy link

gilbert commented Nov 1, 2016

On the other hand, in light of HTTP/2 push, maybe you don't have to worry about script bundling after all, and instead put scripts closest to their component tags?

Edit: https://blog.cloudflare.com/accelerating-node-js-applications-with-http-2-server-push/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants