40 |
41 |
42 | ### `render_async` is here to make your pages show faster to users.
43 |
44 | Pages become faster seamlessly by rendering partials to your views.
45 |
46 | Partials render **asynchronously** and let users see your page **faster**
47 | than using regular rendering.
48 |
49 | It works with Rails and its tools out of the box.
50 |
51 | :sparkles: A quick overview of how `render_async` does its magic:
52 |
53 | 1. user visits a page
54 | 2. `render_async` makes an AJAX request on the controller action
55 | 3. controller renders a partial
56 | 4. partial renders in the place where you put `render_async` view helper
57 |
58 | JavaScript is injected straight into `<%= content_for :render_async %>` so you choose
59 | where to put it.
60 |
61 | :mega: P.S. Join our [Discord channel](https://discord.gg/SPfbeRm) for help and discussion, and let's make `render_async` even better!
62 |
63 | ## :package: Installation
64 |
65 | Add this line to your application's Gemfile:
66 |
67 | ```ruby
68 | gem 'render_async'
69 | ```
70 |
71 | And then execute:
72 |
73 | $ bundle install
74 |
75 | ## :hammer: Usage
76 |
77 | 1. Include `render_async` view helper somewhere in your views (e.g. `app/views/comments/show.html.erb`):
78 | ```erb
79 | <%= render_async comment_stats_path %>
80 | ```
81 |
82 | 2. Then create a route for it `config/routes.rb`:
83 | ```ruby
84 | get :comment_stats, controller: :comments
85 | ```
86 |
87 | 3. Fill in the logic in your controller (e.g. `app/controllers/comments_controller.rb`):
88 | ```ruby
89 | def comment_stats
90 | @stats = Comment.get_stats
91 |
92 | render partial: "comment_stats"
93 | end
94 | ```
95 |
96 | 4. Create a partial that will render (e.g. `app/views/comments/_comment_stats.html.erb`):
97 | ```erb
98 |
99 | <%= @stats %>
100 |
101 | ```
102 |
103 | 5. Add `content_for` in your base view file in the body part (e.g. `app/views/layouts/application.html.erb`):
104 | ```erb
105 | <%= content_for :render_async %>
106 | ```
107 |
108 | ## :hammer_and_wrench: Advanced usage
109 |
110 | Advanced usage includes information on different options, such as:
111 |
112 | - [Passing in a container ID](#passing-in-a-container-id)
113 | - [Passing in a container class name](#passing-in-a-container-class-name)
114 | - [Passing in HTML options](#passing-in-html-options)
115 | - [Passing in an HTML element name](#passing-in-an-html-element-name)
116 | - [Passing in a placeholder](#passing-in-a-placeholder)
117 | - [Passing in an event name](#passing-in-an-event-name)
118 | - [Using default events](#using-default-events)
119 | - [Refreshing the partial](#refreshing-the-partial)
120 | - [Retry on failure](#retry-on-failure)
121 | - [Retry after some time](#retry-after-some-time)
122 | - [Toggle event](#toggle-event)
123 | - [Control polling with a toggle](#control-polling-with-a-toggle)
124 | - [Polling](#polling)
125 | - [Controlled polling](#controlled-polling)
126 | - [Handling errors](#handling-errors)
127 | - [Caching](#caching)
128 | - [Doing non-GET requests](#doing-non-get-requests)
129 | - [Using with Turbolinks](#using-with-turbolinks)
130 | - [Using with Turbo](#using-with-turbo)
131 | - [Using with respond_to and JS format](#using-with-respond_to-and-js-format)
132 | - [Nested async renders](#nested-async-renders)
133 | - [Customizing the content_for name](#customizing-the-content_for-name)
134 | - [Configuration options](#configuration-options)
135 |
136 | ### Passing in a container ID
137 |
138 | `render_async` renders an element that gets replaced with the content
139 | of your request response. In order to have more control over the element
140 | that renders first (before the request), you can set the ID of that element.
141 |
142 | To set ID of the container element, you can do the following:
143 | ```erb
144 | <%= render_async users_path, container_id: 'users-container' %>
145 | ```
146 |
147 | Rendered code in the view:
148 | ```html
149 |
150 |
151 |
152 | ...
153 | ```
154 |
155 | ### Passing in a container class name
156 |
157 | `render_async` renders an element that gets replaced with the content of your
158 | request response. If you want to style that element, you can set the class name
159 | on it.
160 |
161 | ```erb
162 | <%= render_async users_path, container_class: 'users-container-class' %>
163 | ```
164 |
165 | Rendered code in the view:
166 | ```html
167 |
168 |
169 |
170 | ...
171 | ```
172 |
173 | ### Passing in HTML options
174 |
175 | `render_async` can accept `html_options` as a hash.
176 | `html_options` is an optional hash that gets passed to a Rails'
177 | `javascript_tag`, to drop HTML tags into the `script` element.
178 |
179 | Example of utilizing `html_options` with a [nonce](https://edgeguides.rubyonrails.org/security.html#content-security-policy):
180 |
181 | ```erb
182 | <%= render_async users_path, html_options: { nonce: true } %>
183 | ```
184 |
185 | Rendered code in the view:
186 | ```html
187 |
192 |
193 | ...
194 |
195 |
196 |
197 | ```
198 |
199 | > :bulb: You can enable `nonce` to be set everywhere by using [configuration option](#configuration-options) render_async provides.
200 |
201 | ### Passing in an HTML element name
202 |
203 | `render_async` can take in an HTML element name, allowing you to control
204 | what type of container gets rendered. This can be useful when you're using
205 | [`render_async` inside a table](https://github.com/renderedtext/render_async/issues/12)
206 | and you need it to render a `tr` element before your request gets loaded, so
207 | your content doesn't get pushed out of the table.
208 |
209 | Example of using HTML element name:
210 | ```erb
211 | <%= render_async users_path, html_element_name: 'tr' %>
212 | ```
213 |
214 | Rendered code in the view:
215 | ```html
216 |
217 |
218 | ...
219 | ```
220 |
221 | ### Passing in a placeholder
222 |
223 | `render_async` can be called with a block that will act as a placeholder before
224 | your AJAX call finishes.
225 |
226 | Example of passing in a block:
227 |
228 | ```erb
229 | <%= render_async users_path do %>
230 |
Users are loading...
231 | <% end %>
232 | ```
233 |
234 | Rendered code in the view:
235 | ```html
236 |
237 |
Users are loading...
238 |
239 |
240 |
245 | ```
246 |
247 | After AJAX is finished, placeholder will be replaced with the request's
248 | response.
249 |
250 | ### Passing in an event name
251 |
252 | `render_async` can receive `:event_name` option which will emit JavaScript
253 | event after it's done with fetching and rendering request content to HTML.
254 |
255 | This can be useful to have if you want to add some JavaScript functionality
256 | after your partial is loaded through `render_async`.
257 |
258 | You can also access the associated container (DOM node) in the event object
259 | that gets emitted.
260 |
261 | Example of passing it to `render_async`:
262 | ```erb
263 | <%= render_async users_path, event_name: "users-loaded" %>
264 | ```
265 |
266 | Rendered code in view:
267 | ```html
268 |
269 |
270 |
271 |
278 | ```
279 |
280 | Then, in your JavaScript code, you could do something like this:
281 | ```javascript
282 | document.addEventListener("users-loaded", function(event) {
283 | console.log("Users have loaded!", event.container); // Access the container which loaded the users
284 | });
285 | ```
286 |
287 | > :bulb: Dispatching events is also supported for older browsers that don't support Event constructor.
288 |
289 | ### Using default events
290 |
291 | `render_async` will fire the event `render_async_load` when an async partial
292 | has loaded and rendered on the page.
293 |
294 | In case there is an error, the event `render_async_error` will fire instead.
295 |
296 | This event will fire for all `render_async` partials on the page. For every
297 | event, the associated container (DOM node) will be passed along.
298 |
299 | This can be useful to apply JavaScript to content loaded after the page is
300 | ready.
301 |
302 | Example of using events:
303 |
304 | ```js
305 | // Vanilla javascript
306 | document.addEventListener('render_async_load', function(event) {
307 | console.log('Async partial loaded in this container:', event.container);
308 | });
309 | document.addEventListener('render_async_error', function(event) {
310 | console.log('Async partial could not load in this container:', event.container);
311 | });
312 |
313 | // with jQuery
314 | $(document).on('render_async_load', function(event) {
315 | console.log('Async partial loaded in this container:', event.container);
316 | });
317 | $(document).on('render_async_error', function(event) {
318 | console.log('Async partial could not load in this container:', event.container);
319 | });
320 | ```
321 |
322 | ### Refreshing the partial
323 |
324 | `render_async` lets you refresh (reload) the partial by letting you dispatch
325 | the 'refresh' event on the `render_async`'s container. An example:
326 |
327 | ```erb
328 | <%= render_async comments_path,
329 | container_id: 'refresh-me',
330 | replace_container: false %>
331 |
332 |
333 |
334 |
345 | ```
346 |
347 | If you follow the example above, when you click "Refresh comments" button,
348 | `render_async` will trigger again and reload the `comments_path`.
349 |
350 | > :bulb: Note that you need to pass `replace_container: false` so you can later dispatch an event on that container.
351 |
352 | ### Retry on failure
353 |
354 | `render_async` can retry your requests if they fail for some reason.
355 |
356 | If you want `render_async` to retry a request for number of times, you can do
357 | this:
358 | ```erb
359 | <%= render_async users_path, retry_count: 5, error_message: "Couldn't fetch it" %>
360 | ```
361 |
362 | Now render_async will retry `users_path` for 5 times. If it succeeds in
363 | between, it will stop with dispatching requests. If it fails after 5 times,
364 | it will show an [error message](#handling-errors) which you need to specify.
365 |
366 | This can show useful when you know your requests often fail, and you don't want
367 | to refresh the whole page just to retry them.
368 |
369 | #### Retry after some time
370 |
371 | If you want to retry requests but with some delay in between the calls, you can
372 | pass a `retry_delay` option together with `retry_count` like so:
373 |
374 | ```erb
375 | <%= render_async users_path,
376 | retry_count: 5,
377 | retry_delay: 2000 %>
378 | ```
379 |
380 | This will make `render_async` wait for 2 seconds before retrying after each
381 | failure. In the end, if the request is still failing after 5th time, it will
382 | dispatch a [default error event](#using-default-events).
383 |
384 | > :candy: If you are catching an event after an error, you can get `retryCount` from
385 | the event. `retryCount` will have the number of retries it took before the event was dispatched.
386 |
387 | Here is an example on how to get `retryCount`:
388 |
389 | ```erb
390 | <%= render_async users_path,
391 | retry_count: 5,
392 | retry_delay: 2000,
393 | error_event_name: 'it-failed-badly' %>
394 |
395 |
400 | ```
401 |
402 | If you need to pass retry count to the backend, you can pass `retry_count_header` in `render_async`'s options:
403 |
404 | ```erb
405 | <%= render_async users_path,
406 | retry_count: 5,
407 | retry_count_header: 'Retry-Count-Current' %>
408 | ```
409 |
410 | And then in controller you can read the value from request headers.
411 |
412 | ```
413 | request.headers['Retry-Count-Current']&.to_i
414 | ```
415 |
416 | ### Toggle event
417 |
418 | You can trigger `render_async` loading by clicking or doing another event to a
419 | certain HTML element. You can do this by passing in a selector and an event
420 | name which will trigger `render_async`. If you don't specify an event name, the
421 | default event that will trigger `render_async` will be 'click' event. You can
422 | do this by doing the following:
423 |
424 | ```erb
425 | Load comments
426 | <%= render_async comments_path, toggle: { selector: '#comments-button', event: :click } %>
427 | ```
428 |
429 | This will trigger `render_async` to load the `comments_path` when you click the `#comments-button` element.
430 | If you want to remove an event once it's triggered, you can pass `once: true` in the toggle options.
431 | The `once` option is false (`nil`) by default.
432 |
433 | You can also pass in a placeholder before the `render_async` is triggered. That
434 | way, the element that started `render_async` logic will be removed after the
435 | request has been completed. You can achieve this behaviour with something like this:
436 |
437 | ```erb
438 | <%= render_async comments_path, toggle: { selector: '#comments-button', event: :click } do %>
439 | Load comments
440 | <% end %>
441 | ```
442 |
443 | #### Control polling with a toggle
444 |
445 | Also, you can mix interval and toggle features. This way, you can turn polling
446 | on, and off by clicking the "Load comments" button. In order to do this, you need to
447 | pass `toggle` and `interval` arguments to `render_async` call like this:
448 |
449 | ```erb
450 | Load comments
451 | <%= render_async comments_path, toggle: { selector: '#comments-button', event: :click }, interval: 2000 %>
452 | ```
453 |
454 | If you want `render_async` to render the request on load, you can pass `start:
455 | true`. Passing the `start` option inside the `toggle` hash will trigger
456 | `render_async` on page load. You can then toggle off polling by interacting
457 | with the element you specified. An example:
458 |
459 | ```erb
460 | Toggle comments loading
461 | <%= render_async comments_path,
462 | toggle: { selector: '#comments-button',
463 | event: :click,
464 | start: true },
465 | interval: 2000 %>
466 | ```
467 |
468 | In the example above, the comments will load as soon as the page is rendered.
469 | Then, you can stop polling for comments by clicking the "Toggle comments
470 | loading" button.
471 |
472 | ### Polling
473 |
474 | You can call `render_async` with interval argument. This will make render_async
475 | call specified path at the specified interval.
476 |
477 | By doing this:
478 | ```erb
479 | <%= render_async comments_path, interval: 5000 %>
480 | ```
481 | You are telling `render_async` to fetch comments_path every 5 seconds.
482 |
483 | This can be handy if you want to enable polling for a specific URL.
484 |
485 | > :warning: By passing interval to `render_async`, the initial container element
486 | > will remain in the HTML tree and it will not be replaced with request response.
487 | > You can handle how that container element is rendered and its style by
488 | > [passing in an HTML element name](#passing-in-an-html-element-name) and
489 | > [HTML element class](#passing-in-a-container-class-name).
490 |
491 | ### Controlled polling
492 |
493 | You can controller `render_async` [polling](#polling) in 2 manners.
494 | First one is pretty simple, and it involves using the [toggle](#toggle-event)
495 | feature. To do this, you can follow instructions in the
496 | [control polling with a toggle section](#control-polling-with-a-toggle).
497 |
498 | The second option is more advanced and it involves emitting events to the `render_async`'s
499 | container element. From your code, you can emit the following events:
500 | - 'async-stop' - this will stop polling
501 | - 'async-start' - this will start polling.
502 |
503 | > :bulb: Please note that events need to be dispatched to a render_async container.
504 |
505 | An example of how you can do this looks like this:
506 |
507 | ```erb
508 | <%= render_async wave_render_async_path,
509 | container_id: 'controllable-interval', # set container_id so we can get it later easily
510 | interval: 3000 %>
511 |
512 |
513 |
514 |
515 |
534 | ```
535 |
536 | We are rendering two buttons - "Stop polling" and "Start polling". Then, we
537 | attach an event listener to catch any clicking on the buttons. When the buttons
538 | are clicked, we either stop the polling or start the polling, depending on which
539 | button a user clicks.
540 |
541 | ### Handling errors
542 |
543 | `render_async` lets you handle errors by allowing you to pass in `error_message`
544 | and `error_event_name`.
545 |
546 | - `error_message`
547 |
548 | passing an `error_message` will render a message if the AJAX requests fails for
549 | some reason
550 | ```erb
551 | <%= render_async users_path,
552 | error_message: '
Sorry, users loading went wrong :(
' %>
553 | ```
554 |
555 | - `error_event_name`
556 |
557 | calling `render_async` with `error_event_name` will dispatch event in the case
558 | of an error with your AJAX call.
559 | ```erb
560 | <%= render_asyc users_path, error_event_name: 'users-error-event' %>
561 | ```
562 |
563 | You can then catch the event in your code with:
564 | ```js
565 | document.addEventListener('users-error-event', function() {
566 | // I'm on it
567 | })
568 | ```
569 |
570 | ### Caching
571 |
572 | `render_async` can utilize view fragment caching to avoid extra AJAX calls.
573 |
574 | In your views (e.g. `app/views/comments/show.html.erb`):
575 | ```erb
576 | # note 'render_async_cache' instead of standard 'render_async'
577 | <%= render_async_cache comment_stats_path %>
578 | ```
579 |
580 | Then, in the partial (e.g. `app/views/comments/_comment_stats.html.erb`):
581 | ```erb
582 | <% cache render_async_cache_key(request.path), skip_digest: true do %>
583 |
584 | <%= @stats %>
585 |
586 | <% end %>
587 | ```
588 |
589 | - The first time the page renders, it will make the AJAX call.
590 | - Any other times (until the cache expires), it will render from cache
591 | instantly, without making the AJAX call.
592 | - You can expire cache simply by passing `:expires_in` in your view where
593 | you cache the partial
594 |
595 | ### Doing non-GET requests
596 |
597 | By default, `render_async` creates AJAX GET requests for the path you provide.
598 | If you want to change this behaviour, you can pass in a `method` argument to
599 | `render_async` view helper.
600 |
601 | ```erb
602 | <%= render_async users_path, method: 'POST' %>
603 | ```
604 |
605 | You can also set `body` and `headers` of the request if you need them.
606 |
607 | ```erb
608 | <%= render_async users_path,
609 | method: 'POST',
610 | data: { fresh: 'AF' },
611 | headers: { 'Content-Type': 'text' } %>
612 | ```
613 |
614 | ### Using with Turbolinks
615 |
616 | On Turbolinks applications, you may experience caching issues when navigating
617 | away from, and then back to, a page with a `render_async` call on it. This will
618 | likely show up as an empty div.
619 |
620 | If you're using Turbolinks 5 or higher, you can resolve this by setting Turbolinks
621 | configuration of `render_async` to true:
622 |
623 | ```rb
624 | RenderAsync.configure do |config|
625 | config.turbolinks = true # Enable this option if you are using Turbolinks 5+
626 | end
627 | ```
628 |
629 | This way, you're not breaking Turbolinks flow of loading or reloading a page.
630 | It is more efficient than the next option below.
631 |
632 | Another option:
633 | If you want, you can tell Turbolinks to reload your `render_async` call as follows:
634 |
635 | ```erb
636 | <%= render_async events_path, html_options: { 'data-turbolinks-track': 'reload' } %>
637 | ```
638 |
639 | This will reload the whole page with Turbolinks.
640 |
641 | > :bulb: If Turbolinks is misbehaving in some way, make sure to put `<%= content_for :render_async %>` in your base view file in
642 | the `` and not the ``.
643 |
644 | ### Using with Turbo
645 |
646 | On Turbo applications, you may experience caching issues when navigating
647 | away from, and then back to, a page with a `render_async` call on it. This will
648 | likely show up as an empty div.
649 |
650 | If you're using Turbo, you can resolve this by setting Turbo
651 | configuration of `render_async` to true:
652 |
653 | ```rb
654 | RenderAsync.configure do |config|
655 | config.turbo = true # Enable this option if you are using Turbo
656 | end
657 | ```
658 |
659 | This way, you're not breaking Turbos flow of loading or reloading a page.
660 | It is more efficient than the next option below.
661 |
662 | Another option:
663 | If you want, you can tell Turbo to reload your `render_async` call as follows:
664 |
665 | ```erb
666 | <%= render_async events_path, html_options: { 'data-turbo-track': 'reload' } %>
667 | ```
668 |
669 | This will reload the whole page with Turbo.
670 |
671 | > :bulb: If Turbo is misbehaving in some way, make sure to put `<%= content_for :render_async %>` in your base view file in
672 | the `` and not the ``.
673 |
674 | ### Using with respond_to and JS format
675 |
676 | If you need to restrict the action to only respond to AJAX requests, you'll
677 | likely wrap it inside `respond_to`/`format.js` blocks like this:
678 |
679 | ```ruby
680 | def comment_stats
681 | respond_to do |format|
682 | format.js do
683 | @stats = Comment.get_stats
684 |
685 | render partial: "comment_stats"
686 | end
687 | end
688 | end
689 | ```
690 |
691 | When you do this, Rails will sometimes set the response's `Content-Type` header
692 | to `text/javascript`. This causes the partial not to be rendered in the HTML.
693 | This usually happens when there's browser caching.
694 |
695 | You can get around it by specifying the content type to `text/html` in the
696 | render call:
697 |
698 | ```ruby
699 | render partial: "comment_stats", content_type: 'text/html'
700 | ```
701 |
702 | ### Nested async renders
703 |
704 | It is possible to nest async templates within other async templates. When doing
705 | so, another `content_for` is required to ensure the JavaScript needed to load
706 | nested templates is included.
707 |
708 | For example:
709 | ```erb
710 | <%# app/views/comments/show.html.erb %>
711 |
712 | <%= render_async comment_stats_path %>
713 | ```
714 |
715 | ```erb
716 | <%# app/views/comments/_comment_stats.html.erb %>
717 |
718 |
725 |
726 | <%= content_for :render_async %>
727 | ```
728 |
729 | ### Customizing the content_for name
730 |
731 | The `content_for` name may be customized by passing the `content_for_name`
732 | option to `render_async`. This option is especially useful when doing [nested async
733 | renders](#nested-async-renders) to better control the location of the injected JavaScript.
734 |
735 | For example:
736 | ```erb
737 | <%= render_async comment_stats_path, content_for_name: :render_async_comment_stats %>
738 |
739 | <%= content_for :render_async_comment_stats %>
740 | ```
741 |
742 | ### Configuration options
743 |
744 | `render_async` renders Vanilla JS (regular JavaScript, non-jQuery code)
745 | **by default** in order to fetch the request from the server.
746 |
747 | If you want `render_async` to use jQuery code, you need to configure it to do
748 | so.
749 |
750 | You can configure it by doing the following anywhere before you call
751 | `render_async`:
752 |
753 | ```rb
754 | RenderAsync.configure do |config|
755 | config.jquery = true # This will render jQuery code, and skip Vanilla JS code. The default value is false.
756 | config.turbolinks = true # Enable this option if you are using Turbolinks 5+. The default value is false.
757 | config.turbo = true # Enable this option if you are using Turbo. The default value is false.
758 | config.replace_container = false # Set to false if you want to keep the placeholder div element from render_async. The default value is true.
759 | config.nonces = true # Set to true if you want render_async's javascript_tag always to receive nonce: true. The default value is false.
760 | end
761 | ```
762 |
763 | Also, you can do it like this:
764 | ```rb
765 | # This will render jQuery code, and skip Vanilla JS code
766 | RenderAsync.configuration.jquery = true
767 | ```
768 |
769 | Aside from configuring whether the gem relies on jQuery or VanillaJS, you can
770 | configure other options:
771 |
772 | - `turbolinks` option - If you are using Turbolinks 5+, you should enable this option since it supports Turbolinks way of loading data. The default value for this option is false.
773 | - `turbo` option - If you are using Turbo, you should enable this option since it supports Turbo way of loading data. The default value for this option is false.
774 | - `replace_container` option - If you want render_async to replace its container with the request response, turn this on. You can turn this on globally for all render_async calls, but if you use this option in a specific render_async call, it will override the global configuration. The default value is true.
775 | - `nonces` - If you need to pass in `nonce: true` to the `javascript_tag` in your application, it might make sense for you to turn this on globally for all render_async calls. To read more about nonces, check out [Rails' official guide on security](https://edgeguides.rubyonrails.org/security.html). The default value is false.
776 |
777 | ## :hammer_and_pick: Development
778 |
779 | After checking out the repo, run `bin/setup` to install dependencies. Then, run
780 | `rake spec` to run the tests. You can also run `bin/console` for an interactive
781 | prompt that will allow you to experiment. To run integration tests, use
782 | `bin/integration-tests`. For more information, check out [CONTRIBUTING](.github/CONTRIBUTING.md) file, please.
783 |
784 | Got any questions or comments about development (or anything else)?
785 | Join [render_async's Discord channel](https://discord.gg/SPfbeRm)
786 | and let's make `render_async` even better!
787 |
788 | ## :pray: Contributing
789 |
790 | Check out [CONTRIBUTING](.github/CONTRIBUTING.md) file, please.
791 |
792 | Got any issues or difficulties?
793 | Join [render_async's Discord channel](https://discord.gg/SPfbeRm)
794 | and let's make `render_async` even better!
795 |
796 | ## :memo: License
797 |
798 | The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).
799 |
800 | ## Contributors
801 |
802 | Thanks goes to these wonderful people ([emoji key](https://github.com/kentcdodds/all-contributors#emoji-key)):
803 |
804 |
805 |
806 | | [ Nikola Đuza](https://nikolalsvk.github.io) [💬](#question-nikolalsvk "Answering Questions") [💻](https://github.com/renderedtext/render_async/commits?author=nikolalsvk "Code") [📖](https://github.com/renderedtext/render_async/commits?author=nikolalsvk "Documentation") [👀](#review-nikolalsvk "Reviewed Pull Requests") | [ Colin](http://www.colinxfleming.com) [💻](https://github.com/renderedtext/render_async/commits?author=colinxfleming "Code") [📖](https://github.com/renderedtext/render_async/commits?author=colinxfleming "Documentation") [💡](#example-colinxfleming "Examples") | [ Kasper Grubbe](http://kaspergrubbe.com) [💻](https://github.com/renderedtext/render_async/commits?author=kaspergrubbe "Code") | [ Sai Ram Kunala](https://sairam.xyz/) [📖](https://github.com/renderedtext/render_async/commits?author=sairam "Documentation") | [ Josh Arnold](https://github.com/nightsurge) [💻](https://github.com/renderedtext/render_async/commits?author=nightsurge "Code") [📖](https://github.com/renderedtext/render_async/commits?author=nightsurge "Documentation") | [ Elad Shahar](https://eladshahar.com) [💻](https://github.com/renderedtext/render_async/commits?author=SaladFork "Code") [💡](#example-SaladFork "Examples") | [ Sasha](http://www.revzin.co.il) [💻](https://github.com/renderedtext/render_async/commits?author=sasharevzin "Code") [📖](https://github.com/renderedtext/render_async/commits?author=sasharevzin "Documentation") |
807 | | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
808 | | [ Ernest Surudo](http://elsurudo.com) [💻](https://github.com/renderedtext/render_async/commits?author=elsurudo "Code") | [ Kurtis Rainbolt-Greene](https://kurtis.rainbolt-greene.online) [💻](https://github.com/renderedtext/render_async/commits?author=krainboltgreene "Code") | [ Richard Schneeman](https://www.schneems.com) [📖](https://github.com/renderedtext/render_async/commits?author=schneems "Documentation") | [ Richard Venneman](https://www.cityspotters.com) [📖](https://github.com/renderedtext/render_async/commits?author=richardvenneman "Documentation") | [ Filipe W. Lima](https://github.com/filipewl) [📖](https://github.com/renderedtext/render_async/commits?author=filipewl "Documentation") | [ Jesús Eduardo Clemens Chong](https://github.com/eclemens) [💻](https://github.com/renderedtext/render_async/commits?author=eclemens "Code") | [ René Klačan](https://github.com/reneklacan) [💻](https://github.com/renderedtext/render_async/commits?author=reneklacan "Code") [📖](https://github.com/renderedtext/render_async/commits?author=reneklacan "Documentation") |
809 | | [ Gil Gomes](http://gilgomes.com.br) [📖](https://github.com/renderedtext/render_async/commits?author=gil27 "Documentation") | [ Khoa Nguyen](https://github.com/ThanhKhoaIT) [💻](https://github.com/renderedtext/render_async/commits?author=ThanhKhoaIT "Code") [📖](https://github.com/renderedtext/render_async/commits?author=ThanhKhoaIT "Documentation") | [ Preet Sethi](https://www.linkedin.com/in/preetsethila/) [💻](https://github.com/renderedtext/render_async/commits?author=preetsethi "Code") | [ fangxing](https://github.com/fffx) [💻](https://github.com/renderedtext/render_async/commits?author=fffx "Code") | [ Emmanuel Pire](http://blog.lipsumarium.com) [💻](https://github.com/renderedtext/render_async/commits?author=lipsumar "Code") [📖](https://github.com/renderedtext/render_async/commits?author=lipsumar "Documentation") | [ Maxim Geerinck](https://github.com/maximgeerinck) [💻](https://github.com/renderedtext/render_async/commits?author=maximgeerinck "Code") | [ Don](https://github.com/vanboom) [💻](https://github.com/renderedtext/render_async/commits?author=vanboom "Code") |
810 | | [ villu164](https://github.com/villu164) [📖](https://github.com/renderedtext/render_async/commits?author=villu164 "Documentation") | [ Mitchell Buckley](https://github.com/Mbuckley0) [💻](https://github.com/renderedtext/render_async/commits?author=Mbuckley0 "Code") [📖](https://github.com/renderedtext/render_async/commits?author=Mbuckley0 "Documentation") | [ yhirano55](https://github.com/yhirano55) [💻](https://github.com/renderedtext/render_async/commits?author=yhirano55 "Code") [📖](https://github.com/renderedtext/render_async/commits?author=yhirano55 "Documentation") |
811 |
812 |
813 | This project follows the [all-contributors](https://github.com/kentcdodds/all-contributors) specification. Contributions of any kind welcome!
814 |
--------------------------------------------------------------------------------
3 |
4 | 
13 |
14 |
15 | 
22 |
23 | 
38 |
39 | 
