Right now it isn’t possible to publish both doc.a.b and doc.a.c so that the client gets doc.a.{ b, c }. That’s the part I find most surprising.
And with the mergebox, it already does deep diffing (to check equality), the problem is that it only has the ability to send the client top-level fields over DDP. With only the ability to send top-level fields the mergebox is basically useless. If it could send nested fields, there are some places I’d love to use it.
Meteor should be view-layer agnostic
Completely agree and frankly in 2019 this should not even be a contentious issue.
Blaze is a legacy technology and in the wider Javascript ecosystems has basically no market share or compelling technical differentiators.
If anyone is starting a serious application NOW they would be foolish to use Blaze. Just use Vue or React depending on preferences.
I don’t think this is exactly what you’re after (and it’s not production ready) but we’ve been playing with this for the last few weeks, to allow the same client to separately subscribe to multiple fields within the same top level field.
It’s useful for us with our custom tables (with one set of fields) and table exports (with a different set of fields) when combined with custom document schemas (all custom fields reside in a single top level namespace).
Might give you a starting point
https://bitbucket.org/znewsham/meteor-ddp-server/src/master/
Deep equality comparison can generally be done faster than deep diffing (you can abort on the first difference).
Guys & Gals,
This thread is turning into everyone’s wish list. Tiny is here for business not to make all the dreams of us (lazy) developers come true
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support). That’s not their job
What we should really want is:
My 2 cents, now back to work
Listening to this podcast episode about SSR in React (they mention Meteor and Apollo a few times), makes me think there still is a big opportunity for Meteor here as well.
I don’t know if it’s possible to make SSR more plug and play, but just fixing some of the gotchas should already go a long way I think. Looking at how Ben aced the dynamic imports, it should be possible to make this a better dev experience as well. You already see community efforts like this package trying to achieve the same thing.
I have the feeling the JS community is still looking for a go-to solution for this, and out of the box SSR could be a USP that makes a lot of sense for Meteor.
This thread is turning into everyone’s wish list.
Post Your Most-Wanted Features for Meteor seems to be asking for just that.
If the platform is to become live and vibrant, a feature that is important enough will get developed by contributors (e.g. all those I want Vue or Svelte support ). That’s not their job
Vue integration is already a feature that has been developed by contributors. It’s in the official Meteor guide.
View-layer agnosticism would drive away interest.
Why? If developers familiar or partial to a view layer come to Meteor after learning about a first class integration, that is more devs using Meteor and potentially contributing. If a company would like to adopt Meteor progressively, it would be beneficial if they could use their existing front end code base. I’m interested in using a framework where I’m not tied into a view layer or database. Ruby on Rails and Django are view layer agnostic and plenty of people use them.
React HAS to be a first-class citizen
No more than Angular or Vue does.
The React audience is HUGE and are often backed by companies.
Same can be said for Vue (Facebook, Netflix, and Adobe) and Angular (Google, Udemy, MIT).
Not sure what your message is as you seem to agree with me that contributors have carried the torch for Vue. My point is that it’s not up to Tiny to do all this but the community. Let’s make it short and sweet
The post title is ‘Help Tiny’, so we should focus on what is expected from the owning company by the community. First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
PS: I wasn’t aware that Facebook was using Vue in any significant way
Core Vue contributors (especially Akryum) have worked on the integrations for Vue. I don’t know the history of how React came to be a part of Meteor and if core React members made it possible or if MDG helped out, but I imagined the community carried the torch for it as well.
First-class view layers other than React should be up to the community (maybe Angular can be up to Tiny as well, not sure)
Still don’t understand why you think they should be maintaining the React integration but leaving everything else up to the community. It’s up to Tiny whether or not they think supporting the existing integrations is important.
It’s been mentioned in here already, but the creator of Vue worked for MDG and it has been argued that it is an even better fit for Meteor than React. My point is that Meteor can be successful while not favoring one view framework over another.
Notice the bolded part, it’s my opinion. React is by far the dominant view layer see proxy chart (Angular not far behind, but it comes with its own full toolkit). If we want Tiny to be a good shepherd, we need to help them focus on where the money is.
If we’re using google trends, then HTML is by far the dominant view layer!
https://trends.google.com/trends/explore?cat=31&q=Vue.js,React,Angular,html
Lol. I have never typed “vue.js” into Google when searching for Vue stuff.
A bit better: https://trends.google.com/trends/explore?cat=31&q=Vue,React,Angular
– 25 vs 100 for React
I imagine The State of Javascript and npm weekly downloads (6,117,132 for React, 1,157,084 for Vue and 465,898 for Angular) would give a better snapshot of how view layers are comparing in popularity.
I think the problem with SSR is that the specific tools you are using require a different set of configuration. For example, in one project, I use: React, React Router, npdev:collections, Material-UI (JSS), react-helmet-async, staringatlights:fast-render, and npdev:react-loadable. In another I use Svelte, svelte-loadable/npdev:svelt-loadable, staringatlights:fast-render, and might use Apollo (currently using straight Meteor pub/sub). These two projects will require a completely different set of tools to be configured in SSR on both the server and client.
I’ve also read that SSR memory leaks in React aren’t exclusive to Meteor, and are just generally hard to manage. In my main React project, I can’t seem to get it to stop leaking memory, though I have significantly reduced (slowed) the leak (this indicates multiple leaks). I currently suspect either Material UI, or uniforms as the culprit - neither satisfies React’s Strict mode, which means either could be creating “side effects” on mount, and causing the leak. (Or possibly some core incompatibility between hooks and/or the mongo driver and Meteor’s Fibers.) I’m not sure yet.
Opinionated Starters (like mine for react and svelte) are probably the way to make this easier.
I find SSR is a little over-rated, in general.
It’s a micro optimization, but gets pushed around like it’s required. You can have a wonderful non-ssr experience with a service worker.
Another feature I’m really interested in is a code sandbox for Meteor.
When MeteorPad went down, a lot of knowledge and examples were lost. It was frustrating to find a blog post I’d read before with the solution to my problem but not be able to access the example.
I participate in other communities (namely Vue), where it is easier to give and get answers to common problems because of the insistence on a small reproduction in Codepen or Codesandbox.io. I happily pay for Codesandbox because of the templates that are readily available, linting, and ease of isolating problems quickly. I’d be thrilled if there were template for Meteor. I’m not sure how Atmosphere packages could be required and DDP could be emulated or if it’s even possible without spinning up an instance of an application.
I’d be open to paying for one from MDG, provided I knew that they would continue support for it in the future.
Interesting take, thanks! Any tips for tutorials on this?
Google has the best documentation I’ve seen: https://developers.google.com/web/fundamentals/primers/service-workers
import React from 'react';
import { render } from 'react-dom';
import Whatever from './Whatever'
render(<Whatever />, document.getElementById('whatever-target'));
This is more first-class than create-react-app, which magically sets up an html div with id="root".