We Keep Coding

Django monolith: How to render front-end while still loading one function from backend

I have a django 4.0 monolith project; however, one of the objects (a graph) that I pass to the template context to display in the html is slow to load.
I'd like to have the rest of the page render first, while this function is still running/loading. That way, users can see the rest of the page while the graph is still loading. Thoughts on the best approach to this?
I tried creating a custom tag to load the graph, but the browser still waited for the everything to load before showing anything on the page.
I'm wondering if some type of javascript call would accomplish this. Perhaps an ajax call? Or the asyncio python package?

Does ReactJS create the .js file for the web too?

I've never used react js and I have only dabbled with node's 'hello world' program.
I'm wondering if react works in such a way that if, say you add an <input type="text" /> tag, when you submit the form will react automatically handle the return of the data or do you need to separately write a client side .js file to handle the ajax data send to server?
Bonus: What is that type of framework called where it creates the two-way interaction automatically?
Apologies for what may be perceived as a basic question, but my beginner level comprehension of javascript hasn't completely got to grips with understanding what the docs actually mean.

Nope -- React is just a framework.
If you want to build a 'consolidated' javascript file that contains everything you need for your website, take a look at tools like webpack (or even better: create-react-app)
Form data is is submitted depending on how you structure your form, and that process is dictated a bit by HTML and a bit by your custom javascript.
To send AJAX based data, take a look at the 'fetch' API.
To manage the interaction between React, the data you're rendering, and other systems (like your server) take a look at Flux or Redux.

It really depend on how you write your application. React framework just render the "View" of your application.
Is you use a basical <form></form> with action the browser will automatically send the data into the "action" url attribute.
But you can just simulate a send of your form into a service/server/fake treatment and manage your return statement.

Well I never used React but, it's a javascript framework that has the same basic structure that Angular and Vue. Well REACT has directives that you can handle the data to send from the view into the component.js. If you want to send data to server you need to use libraries like 'axios' that you can import into you component and use it.

Can one render a .pvd document/scene via paraviewweb or vtk.js without server side?

There are examples (especially in vtk.js that shows .VTP load) that indicate that all rendering capabilities are in there, by what about file format support: can one render a .pvd scene file directly on client side with no rendering/prerendering server on the backend (say on jsfiddle)?
Or any convertion pipeline that would turn traditional paraview .pvd into least

Using VTK.js, no rendering is done on the server. All the rendering is done on the client using WebGL.
If by rendering, you mean processing here are some info:
Currently, to load a VTP file with VTK.js, you need to pre-process it and use the vtkHttpDataSetReader to load the chunks created. This behavior has been implemented to handle most of the files handled by ParaView and VTK.
However, if your VTP files are not compressed (ASCII files), you could write a dedicated reader. The same behavior has been implemented for the vtkOBJReader. See the OBJReader example.
EDIT:
The VTP file reader I mentioned in my original message has been implemented. It's named vtkXMLPolyDataReader. See the GeometryViewer example.

Best way for dynamic interface, loaded from database, in React

I need to rewrite a webapp, and I would like to do it in React.
How it currently works is that in the database there's a row for each "page", which could be something like
{
row: 1,
column: 2,
width: 2,
height: 1,
data: 'Why hello there',
componentType: 'Box'
}
So, I have two problems here:
One: I would like to dynamically load a React component ("Box") that I did not know about at run-time.
Two: Is there some obvious way of doing the component/layout switching here? I know about react-routes, but all the tutorials I have seen shows it to be a lot more "static" (where you basically already know all your views and routes before the app starts, and where it doesn't really seem possible to get that data from a database)

The idea here is to render a version of your app that is essentially "blank". Whether it be through a splash screen or loading spinners, or some combination of the two, or something else.
Then after the app mounts, in your componentDidMount method, you do an http request to an API running on a server that fetches data from a database and returns your data in a format your webapp understands (probably JSON). Then you populate your app with the returned data, turning off any loading screens or spinners when it's done.
Check out this example from the React docs.

You can use webpack dynamic bundle loading

ReactJS server-side rendering vs client-side rendering

I just have began to study ReactJS and found that it gives you 2 ways to render pages: server-side and client-side. But, I can't understand how to use it together. Is it 2 separate ways to build the application, or can they be used together?
If we can use it together, how to do it - do we need to duplicate the same elements on the server side and client side? Or, can we just build the static parts of our application on the server, and the dynamic parts on the client side, without any connection to the server side that was already pre-rendered?

For a given website / web-application, you can use react either client-side, server-side or both.
Client-Side
Over here, you are completely running ReactJS on the browser. This is the simplest setup and includes most examples (including the ones on http://reactjs.org). The initial HTML rendered by the server is a placeholder and the entire UI is rendered in the browser once all your scripts load.
Server-Side
Think of ReactJS as a server-side templating engine here (like jade, handlebars, etc...). The HTML rendered by the server contains the UI as it should be and you do not wait for any scripts to load. Your page can be indexed by a search engine (if one does not execute any javascript).
Since the UI is rendered on the server, none of your event handlers would work and there's no interactivity (you have a static page).
Both
Here, the initial render is on the server. Hence, the HTML received by the browser has the UI as it should be. Once the scripts are loaded, the virtual DOM is re-rendered once again to set up your components' event handlers.
Over here, you need to make sure that you re-render the exact same virtual DOM (root ReactJS component) with the same props that you used to render on the server. Otherwise, ReactJS will complain that the server-side and client-side virtual DOMs don't match.
Since ReactJS diffs the virtual DOMs between re-renders, the real DOM is not mutated. Only the event handlers are bound to the real DOM elements.

Image source: Walmart Labs Engineering Blog
NB: SSR (Server Side Rendering), CSR (Client Side Rendering).
The main difference being that with SSR, the servers response to the clients browser, includes the HTML of the page to be rendered.
It is also important to note that although, with SSR, the page renders quicker. The page will not be ready for user interaction until JS files have been downloaded and the browser has executed React.
One downside is that the SSR TTFB (Time to First Byte) can be slightly longer. Understandably so, because the server takes some time creating the HTML document, which in turn increases the servers response size.

I was actually wondering the same researching quite a bit and while the answer you are looking for was given in the comments but I feel it should be more prominent hence I'm writing this post (which I will update once I can come up with a better way as I find the solution architecturally at least questionable).
You would need to write your components with both ways in mind thus basically putting if switches everywhere to determine whether you are on the client or the server and then do either as DB query (or whatever appropriate on the server) or a REST call (on the client). Then you would have to write endpoints which generate your data and expose it to the client and there you go.
Again, happy to learn about a cleaner solution.

Is it 2 separate ways to build the application, or can they be used together?
They can be used together.
If we can use it together, how to do it - do we need to duplicate the
same elements on the server side and client side? Or, can we just
build the static parts of our application on the server, and the
dynamic parts on the client side, without any connection to the server
side that was already pre-rendered?
It's better to have the same layout being rendered to avoid reflow and repaint operations, less flicker / blinks, your page will be smoother. However, it's not a limitation. You could very well cache the SSR html (something Electrode does to cut down response time) / send a static html which gets overwritten by the CSR (client side render).
If you're just starting with SSR, I would recommend start simple, SSR can get very complex very quickly. To build html on the server means losing access to objects like window, document (you have these on the client), losing ability to incorporate async operations (out of the box), and generally lots of code edits to get your code SSR compatible (since you'll have to use webpack to pack your bundle.js). Things like CSS imports, require vs import suddenly start biting you (this is not the case in default React app without webpack).
The general pattern of SSR looks like this. An Express server serving requests:
const app = Express();
const port = 8092;
// This is fired every time the server side receives a request
app.use(handleRender);
function handleRender(req, res) {
const fullUrl = req.protocol + '://' + req.get('host') + req.originalUrl;
console.log('fullUrl: ', fullUrl);
console.log('req.url: ', req.url);
// Create a new Redux store instance
const store = createStore(reducerFn);
const urlToRender = req.url;
// Render the component to a string
const html = renderToString(
<Provider store={store}>
<StaticRouter location={urlToRender} context={{}}>
{routes}
</StaticRouter>
</Provider>
);
const helmet = Helmet.renderStatic();
// Grab the initial state from our Redux store
const preloadedState = store.getState();
// Send the rendered page back to the client
res.send(renderFullPage(helmet, html, preloadedState));
}
My suggestion to folks starting out with SSR would be to serve out static html. You can get the static html by running the CSR SPA app:
document.getElementById('root').innerHTML
Don't forget, the only reasons to use SSR should be:
SEO
Faster loads (I would discount this)
Hack : https://medium.com/#gagan_goku/react-and-server-side-rendering-ssr-444d8c48abfc