Seeking Community Input: Meteor.js Roadmap

harry97 · June 23, 2023, 3:21pm

I support most of the items on this list except for these two:

Bring Redis-oplog to the core;

I’m afraid that after putting in work to move redis-oplog to the core, change streams would become better making this move not only obsolete but wasted effort which Meteor in a dire need of. So this must be thoroughly investigated upfront.

Honestly, it’s not that pressing. Meteor doesn’t need to double down on either strategy, at least for now. Sometimes, not doing anything is the way to go. We just need to wait things out and time will reveal the best route just like the fibers/es6 situation. For the mean time, ensure devs working on redis-oplog like @storyteller are in a good financial position to allocate time for it while keeping an eye on change streams.

Finally, if you guys think there’s a package that must be brought to the core, it’s gotta be meteor-desktop.

Better file upload package;

I outright don’t get this point at all, may some of you guys share you pain points when dealing file uploads in Meteor? I’ve never had any issues building file upload features into my applications whether building a custom/vanilla solution that directly upload files to AWS or using something like ostrio:files or reaction-file-collections. @dr.dimitru even proposed creating a lighter alternative here.

There’re many great points voiced by the community but for the sake of brevity I’ll use @storyteller reply to comment on few stuff.

Storybooks

Storybooks came out of Meteor. Right now to integrate them with Meteor is painful. At the very least we should have an extension for Storybooks to provide stubs or something to make it run. I think there is a good potential here for an extension that would allow you to set different values that could be switched around in the interface like different users and so on.

I also second Jan Storybooks recommendation. The spirit of Meteor 3.0 is to align Meteor again with the rest of Node.js ecosystem and stop blocking the developers from trying out what the rest of Node.js community has to offer which makes this an absolute must. Mind you, Storybook not working with Meteor was one of the reasons forcing Vulcan to switch off of Meteor. If Meteor is determined to keep current developers and attracting new ones Meteor has gotta to play nicely with the rest of Node.js ecosystem whilst keeping its own Mantra/core philosophy intact.

github.com/VulcanJS/Vulcan

Vulcan + Storybook Discussion

opened 02:19PM - 24 Mar 18 UTC

closed 02:18PM - 10 May 19 UTC

jefflau

enhancement question

## Problem Storybook does not understand how to parse the meteor npm imports.… ## Possible Solution After some playing around I managed to get it to work if I extract all Vulcan packages and higher order components that contain queries into a container component and the 'dumb' components just contain the UI. This component has no UI components inside it and it passes the Vulcan components to its children. This allows you to import the non-container components into Storybook and pass it mock functions and Components that are not from Vulcan as props into your dumb components. The container components will not be imported into your stories. It gets a little more complicated with nested components as you need to mock even more components and then pass them through. ## Thoughts Components have to be more verbose and have separate files for each. Must avoid imports from Meteor/Vulcan in your storybook tested components. However promotes better testing practice as all testable components needs to be pure(ish), they can't even have a single Meteor import, so promotes separation of concerns of your components to container vs UI components. Vulcan's `registerComponent` makes it quite easy to mock the components as all of the components you need to pass as prop are contained under one object. Makes me think about keeping components pure by using the `recompose` library to map props and not directly import them in to make it easier to mock them out. Jest allows you to setup mocks for certain paths. I'm not that experienced with Storybook, so maybe there is a way to mock out modules such as Meteor in the way Jest mocks it out. ## Things that need to be worked out I haven't figured out how to import css in yet such as bootstrap, but that isn't Vulcan specific so should be worked out easily. ## Code ```js // ClientItem.js import React from 'react' const ClientsItem = ({ client, currentUser, check, columns, Components }) => ( <tr> {columns.map((column, i) => ( <td key={column.field}> <column.component document={client} /> </td> ))} <td> {check(currentUser, client) ? ( <Components.ModalTrigger label="Edit Client"> <Components.ClientsEditForm currentUser={currentUser} documentId={client._id} /> </Components.ModalTrigger> ) : null} </td> </tr> ) export default ClientsItem ``` ```js // ClientsItemContainer.js import React, { PropTypes, Component } from 'react' import { registerComponent, Components } from 'meteor/vulcan:core' import { withProps, compose } from 'recompose' import { Link } from 'react-router' import Clients from '../../modules/clients/collection.js' import ClientsItem from './ClientsItem' const enhance = compose( withProps(ownerProps => ({ check: Clients.options.mutations.edit.check, Components })) ) const ClientsItemContainer = enhance(ClientsItem) registerComponent('ClientsItem', ClientsItemContainer) export default ClientsItemContainer ``` ```js // clientItem.stories.js import React from 'react' import { storiesOf } from '@storybook/react' import { action } from '@storybook/addon-actions' import { linkTo } from '@storybook/addon-links' import { Button, Welcome } from '@storybook/react/demo' import ClientsItem from '../components/clients/ClientsItem' import { Link } from 'react-router' import moment from 'moment' const columns = [ { label: 'Name', field: 'firstName', order: 10, component: ({ document: d }) => ( <Link to={`/client/${d._id}`}>{`${d.firstName} ${d.lastName}`}</Link> ), sort: true }, { label: 'Last Interaction', field: 'lastInteraction', order: 10, component: ({ document: d }) => d.lastInteraction ? ( <div> {moment(d.lastInteraction).format('dddd, MMMM Do YYYY, hh:mm:ss')} </div> ) : ( 'N/A' ), sort: true } ] const ComponentsMocks = { ModalTrigger: () => <div>Edit Client</div>, EditForm: () => <div /> } storiesOf('Client Single', module).add('with Text', () => ( <ClientsItem check={() => true} Components={ComponentsMocks} columns={columns} client={{ _id: 123, firstName: 'Jeff', lastName: 'Lau', lastInteraction: new Date() }} /> )) ```

github.com/storybookjs/storybook

Importing Meteor packages (VulcanJS integration)

opened 01:32AM - 01 Apr 18 UTC

closed 02:19PM - 02 Feb 21 UTC

SachaG

compatibility with other tools

A lot of [VulcanJS](http://http://vulcanjs.org/) would love to be able to use St…orybook, but the problem is that Vulcan relies a lot on Meteor packages, which if I'm not mistaken cannot currently be imported inside Storybook. And even if we could get rid of most exports in Vulcan component files and end up with "pure" React files, there is still the issue that Vulcan uses a global component system, where instead of doing `import MyComponent`, you can just write `<Components.MyComponent/>` (this is in order to enable theming among other things). I know there's probably no easy workaround currently, but I would love to start a discussion about how to get Storybook working with Vulcan, even if it requires us changing some thing internally?

Browser policy packages

The browser policy packages haven’t had an update in a while to a point that other solutions started to get recommended. Personally I would like to take a look on them and give them a refresh and see if there is anything specific that Meteor can specifically offer over having a competing NPM package. If we can’t offer anything extra then we should deprecate them.

I’m all for deprecating them as suggested in Deprecate browser policy packages · Issue #11424 · meteor/meteor · GitHub

Desktop, offline and PWA
I would really like to see Electron or similar integration with Meteor. Together with that also improved options on PWA and offline capabilities and caching. Maybe something along the lines of SyncedStore

PWA is nice and all and a one size fit all solution but meteor-desktop must come first. A quick search in the forums yields many results of users complaining about meteor-desktop failing behind.

Always care for your day-ones, “true-believers” in Eric Hoffer words, and then branch out and try to please others. This loops back to my philosophy about caring for your “fanatics” and core nucleus of “true believers” which I lamented on before

Minimongo improvements

Minimongo was one of the things that was truly unique about Meteor like Meteor-accounts but the times are changing. I’ve been looking into this lately and I’m thinking we can use mWater/minimongo as a starting point then including inspirations from mingo, sift.js, nedb.

Minimongo must be made an independent library while adding features like aggregations, indexing and support for geo operators.

You can learn more about Minimongo shortcomings here.

Capacitor

Replacing Cordova with Capacitor fits the whole narrative of Meteor 3.0 and updating the underlying tools used in Meteor just like we did with Express/Connect. But again, it’s not urgent and we need to weigh the pros/cons vs current implementation.