svelte-on-rails 0.0.43 → 0.0.45
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 6ff301ac1c131b28f869668ca522cef6127e3d0946ed87b41da478555048fd8e
|
4
|
+
data.tar.gz: 4acb430643e3b6962c595299e2265c7c1075eb11c65eccb08b0fbc7ccc08e6b5
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 67fc3e82acf84cf6e09a4eded78d0ab8cd74b4bee8b92a91438382205e4f81c6f4fa5f443c6e4ba06ba935ae7799e1ea3a7fe3e26c9306ec7a8696766162526a
|
7
|
+
data.tar.gz: f6f4564ded3293a4e6b37b65bf1557b88f69faba8e9ae0c7b857921b3733b73f144924ce81456b857d437dc0e9bf049ef174d1dd799355ba031e448514528690
|
data/README.md
CHANGED
@@ -3,18 +3,22 @@
|
|
3
3
|
Seamless and robust Svelte in Rails integration.
|
4
4
|
|
5
5
|
By default, and when installed together with `@hotwired/turbo-rails`, it renders
|
6
|
-
svelte components on first request server side («SSR») and for subsequent
|
7
|
-
requests it provides a empty tag
|
6
|
+
svelte components on the first request server side («SSR») and for subsequent
|
7
|
+
requests it provides a empty tag which is mounted on the frontend
|
8
|
+
by the associated npm package [@csedl/svelte-on-rails](https://www.npmjs.com/package/@csedl/svelte-on-rails).
|
8
9
|
|
9
10
|
This way svelte works perfectly together with turbo. You will never notice
|
10
|
-
this unpleasant «blink» on the frontend and
|
11
|
-
|
11
|
+
this unpleasant «blink» on the frontend and is optimised for maximum
|
12
|
+
performance. SSR compilation is done by vite.
|
12
13
|
|
13
|
-
|
14
|
-
This all is developed on Rails-7 together with `vite_rails`.
|
14
|
+
All this is developed on Rails-7 together with `vite_rails`.
|
15
15
|
|
16
16
|
Thanks to [shakacode](https://github.com/shakacode/react_on_rails)
|
17
|
-
and [ElMassimo](https://github.com/ElMassimo)
|
17
|
+
and [ElMassimo](https://github.com/ElMassimo) for inspiring and helping me with their gems.
|
18
|
+
|
19
|
+
**STATUS** This gem is in early development but ready to use for curious developers.
|
20
|
+
It has a 100% test coverage, all tests pass when triggered indiviudally.
|
21
|
+
Running all tests together fails for some tests (ToDo).
|
18
22
|
|
19
23
|
If you have issues, please open one and contributors are welcome!
|
20
24
|
|
@@ -111,34 +115,26 @@ Within the config file, there are mainly two important tags:
|
|
111
115
|
|
112
116
|
## Check if it all works
|
113
117
|
|
114
|
-
|
115
|
-
|
116
|
-
|
117
|
-
- Rendered HelloWorld.svelte server-side: 0.075ms
|
118
|
-
|
119
|
-
On the rails console and you will see «Greetings from svelte»
|
120
|
-
on your view with a styled «Increment» button.
|
121
|
-
Styles you find within the svelte component.
|
122
|
-
Click this button and see that the component is alive.
|
118
|
+
Server Side Rendering (SSR) is a parallel pipeline to client side rendering.
|
119
|
+
Both should return the same html. And your global styles should be applied same way
|
120
|
+
for both cases. For 95% of use cases this is the case.
|
123
121
|
|
124
|
-
|
125
|
-
|
122
|
+
For check the **ssr pipeline** you can pass the options `ssr: true` and `hydrate: false`
|
123
|
+
to the view helper. That Way you will see a dead html (no javascript is working).
|
126
124
|
|
127
|
-
|
128
|
-
|
129
|
-
you would see the same html, and the styled button,
|
130
|
-
but the increment button would not work.
|
125
|
+
For check the **client side pipeline** you can pass the option `ssr: false` and
|
126
|
+
`hydrate: true` to the view helper.
|
131
127
|
|
132
|
-
|
133
|
-
npm package, for making sure that thisk setup is working.
|
134
|
-
So please check the logs on your browser.
|
128
|
+
If both are looking similar, you are good to go.
|
135
129
|
|
136
130
|
### Import statements
|
137
131
|
|
138
|
-
|
139
|
-
|
132
|
+
The most importand import statements that are served by this gem are included in the
|
133
|
+
hello world component and by that they are also within the testing scope. So you can
|
134
|
+
be sure that they are working. If importand statements are missing there, pelase
|
135
|
+
tell me.
|
140
136
|
|
141
|
-
Among others
|
137
|
+
Among others, working statements are:
|
142
138
|
|
143
139
|
- `import svg from '../example.svg?raw'`
|
144
140
|
- `<script lang="ts">` (svelte component with typescript syntax)
|
@@ -149,7 +145,7 @@ Among others there are
|
|
149
145
|
|
150
146
|
Usual vite has a `vite.config.ts` file, that is used for the client side precompilation.
|
151
147
|
|
152
|
-
By running this installer it adds a npm runner so that you can do `npm run build:ssr`
|
148
|
+
By running this installer it adds `vite-ssr.config.ts` and a npm runner so that you can do `npm run build:ssr`
|
153
149
|
which does the server side precompilation.
|
154
150
|
|
155
151
|
The same job is triggered alongside `rails assets:precompile` for production environments.
|
@@ -179,33 +175,6 @@ loaded on very first load to the frontend, then the most work is done
|
|
179
175
|
in frontend and the server is relieved, except on initial request.
|
180
176
|
You will see no unpleasant «blink» on the page.
|
181
177
|
|
182
|
-
## Styles
|
183
|
-
|
184
|
-
For 99% of use cases you can just skip this chapter.
|
185
|
-
|
186
|
-
You can simply work with global styles as well as styles within the svelte component.
|
187
|
-
|
188
|
-
A server-side rendered svelte component has 2 states:
|
189
|
-
|
190
|
-
#### Before hydration
|
191
|
-
|
192
|
-
- The `svelte_component` view helper renders the styles contained within the component
|
193
|
-
into a style tag within the component's wrapper element. This has to be done this way because of Turbo.
|
194
|
-
- In very, very rare cases, global styles are not applied in the same way as after hydration.
|
195
|
-
|
196
|
-
#### After hydration
|
197
|
-
|
198
|
-
- Svelte adds a style tag inside the header
|
199
|
-
- Svelte renders the component again, which removes the style tag inside the component wrapper.
|
200
|
-
|
201
|
-
#### If you notice a "blink"
|
202
|
-
|
203
|
-
For the app to look stable, both states must appear in the same way.
|
204
|
-
Normally this is the case. But if there are problems,
|
205
|
-
or you want to see the state before hydration, for development purposes, you can pass
|
206
|
-
the `hydrate: false` option to the view helper,
|
207
|
-
and no hydration will happen for this component.
|
208
|
-
|
209
178
|
## More rake tasks
|
210
179
|
|
211
180
|
This tasks are more for testing/playground purposes
|
@@ -260,6 +229,47 @@ The current test cases including (among others):
|
|
260
229
|
create a completely new rails app, running the full installer and check if a hello World component is visible and javascript is working.
|
261
230
|
run assets:precompile within a rails app and check if the gem does its precompiling too.
|
262
231
|
|
232
|
+
## Understanding the process
|
233
|
+
|
234
|
+
**Why not client and server rendering in one process?**
|
235
|
+
|
236
|
+
That was my idea! `application.js` which is the usual entry point for the client
|
237
|
+
side could live on the same assets and manifest like svelte components that are
|
238
|
+
compiled as chunks which each is its own entry point. This failed:
|
239
|
+
|
240
|
+
- The `vite-plugin-ruby` did not support this: it constrained all to one entry point.
|
241
|
+
- See how fat the `vite-ssr.config.ts`. For the client side this is not necessary.
|
242
|
+
|
243
|
+
At the end, I decided to split the process. But that is not the last decision.
|
244
|
+
|
245
|
+
**Why not compiling server side purely by rollup?**
|
246
|
+
|
247
|
+
Advantages would be much slimmer packages and faster compilation. On the first
|
248
|
+
step i did this and i backed up a working and tested code on the branch [rollup-ssr](https://gitlab.com/sedl/svelte-on-rails/-/blob/rollup-ssr/BRANCH_INFO.md?ref_type=heads).
|
249
|
+
|
250
|
+
I decided to use Vite to bring the client and server side rendering
|
251
|
+
closer together.
|
252
|
+
|
253
|
+
But this, too, is not the last decision.
|
254
|
+
|
255
|
+
For now we proceed with vite.
|
256
|
+
|
257
|
+
**How does it work now?**
|
258
|
+
|
259
|
+
Client side rendering is done by vite like usual.
|
260
|
+
|
261
|
+
Server side rendering is triggered, similar to [vite_rails](https://vite-ruby.netlify.app/guide/deployment.html)
|
262
|
+
on `assets:precompile`, and, if `watch_changes` is configured,
|
263
|
+
which is default for development, it is triggered
|
264
|
+
on every change of a `*.svelte` file within the configured `components_folder`.
|
265
|
+
|
266
|
+
On the server side only the `*.svelte` files are served. Theyr included
|
267
|
+
assets are linked to the client side assets folder, which is mapped by `manifest.json`.
|
268
|
+
|
269
|
+
Then, vite has two output folders: `vite-dev` for development and `vite` for production.
|
270
|
+
Within `vite-ssr.config.ts`, by the `RAILS_ENV` variable, is decided which one is used.
|
271
|
+
|
272
|
+
|
263
273
|
## Licence
|
264
274
|
|
265
275
|
License is MIT
|
@@ -13,7 +13,6 @@
|
|
13
13
|
|
14
14
|
|
15
15
|
<h1>SSR / Client side rendering test</h1>
|
16
|
-
<p>On the always client side rendered components you will see a unpleasant «blink» on the initial request.</p>
|
17
16
|
<p>After rendering both, client and server side rendered components, must look similar for making sure that on ssr:
|
18
17
|
:auto (which is default)
|
19
18
|
no unpleasant «blink» is appearing.</p>
|
@@ -30,6 +29,7 @@
|
|
30
29
|
|
31
30
|
<hr>
|
32
31
|
<h3>Always rendered client side</h3>
|
32
|
+
<p>Here you will see a unpleasant «blink» on the initial request.</p>
|
33
33
|
<div class="client-only">
|
34
34
|
<% components.each do |component| %>
|
35
35
|
<%= svelte_component(component, ssr: false, hydrate: true, title: component) %>
|