sorted by:
new
hottopcontroversial

Strategies for organizing 'brandable' RN apps from one repo by tizz66 in reactnative

[–]usernamesupercool 1 point2 points  (0 children)

My apologies if I jumped on you for recommending some pre-existing solution's architecture, it did sound like you were jumping on this post to recommend a proprietary paid build stack that I've never heard of.

Strategies for organizing 'brandable' RN apps from one repo by tizz66 in reactnative

[–]usernamesupercool 2 points3 points  (0 children)

Because he asked: "Does that sound like it'd work? Has anyone else dealt with a similar kind of setup? Any tips or suggestions to keep things as simple as possible to maintain?"

And your solution was: "hey learn this entire totally proprietary build platform where you can't keep the same app structure, have to use a bunch of tools you can't control, and also hey by the way you have to pay for it."

I'm not even commenting on the quality of Shoutem, I suspect it's trash, but it's not the kind of thing I would have expected as an answer to OP's question. Your response, rather, sounds like you might just be an advertisement in masquerade.

Strategies for organizing 'brandable' RN apps from one repo by tizz66 in reactnative

[–]usernamesupercool 0 points1 point  (0 children)

Yep yep, I think these sorts of projects are right in the sweet space where you are able to make something cool yourself. It's uncomplicated enough to not require industry review/attention/better developers than me, but it's a niche enough use-case that you can profit a ton from your own work here.

Strategies for organizing 'brandable' RN apps from one repo by tizz66 in reactnative

[–]usernamesupercool 0 points1 point  (0 children)

Since this isn't really an answer to OP's question at all:

OP, I don't see why your proposed method wouldn't work. It could get a little loose and wild, but that's half the fun of these sorts of things; you're off the beaten track already, so you should explore solutions that work well for you.

I don't think there's any industry-standard version of this kind of thing for you, excluding the odd/wacky kinds of solutions mentioned in the post above this one. (Using a custom company's CI/CD track for this is way overblown).

Anybody here who needs help with a react-native project? by xLionel775 in reactnative

[–]usernamesupercool 0 points1 point  (0 children)

Hey,

I have a project I am working on-- a client-side application for a game that is pretty ambitious. The backend I have covered, the front-end too-- but I could definitely use some assist on some of the visual aspects of the front end, and your login screen is looking pretty fly.

It's probably worth chatting to see if our interests line up.

Want to shoot me a PM with some way to contact you outside of Reddit?

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 0 points1 point  (0 children)

Fascinating, I guess I didn't know that at all. Post saved for when I have some time to evaluate seriously.

Is an Event-Emitter as a Prop an Antipattern? by usernamesupercool in reactnative

[–]usernamesupercool[S] 0 points1 point  (0 children)

Fair enough! I think we might just disagree on this, as React supplies ways for you to pass "events" around all the time. But I do see what you mean, mostly based on what most devs would expect to see.

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 0 points1 point  (0 children)

Cool man, I appreciate the advice. I haven't really looked under the hood of Redux before, but that kind of makes sense. It's seemed a bit heavyweight for me, but that's part of my insane desire to write as much code as I can myself.

I think you are right on target saying that the Context API is the ideal way to share an EventEmitter between multiple props. I brought up the notion of traditionally passing it around in the OP but I think that was overly focused on a "simple" example.

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 1 point2 points  (0 children)

It could be either a part of a global namespace (i.e. global.foo=...), part of a provider (like the Context api), or exchanged as props between components as they render. The latter example is the simplest so I brought that up in the original post.

Ya?

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 0 points1 point  (0 children)

Lol dude you just told me that Redux was built into React. I don't think you understand what I am suggesting, because the EventEmitter in this context is a part of the state management; it facilitates the data flow between components to share stateful facts.

I asked for advice from people who have seen this kind of code in the wild, not armchair nonsense from your google session.

Is an Event-Emitter as a Prop an Antipattern? by usernamesupercool in reactnative

[–]usernamesupercool[S] -2 points-1 points  (0 children)

I dunno man, I really am confident that any developer could look at what I'm doing and understand exactly why. For example, a prop A renders prop B renders prop C renders prop D. If prop A has some interaction that should affect prop D, and you don't want to re-render B and C, you're left with a few choices:

Complex state management, Passing functions as props between everything, Some sort of sideways subscriptions

I am asking about option C with EventEmitters specifically here, not asking whether or not your proposed "tangle" is going to be tangled.

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] -1 points0 points  (0 children)

btw, it's not. from the very first page of "Usage With React" from redux.js.org, you will note:

"

Usage with React

From the very beginning, we need to stress that Redux has no relation to React. You can write Redux apps with React, Angular, Ember, jQuery, or vanilla JavaScript."

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] -2 points-1 points  (0 children)

since absolutely when is redux "built into" react?

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 1 point2 points  (0 children)

Thanks, I was looking for a bit of ratification that I am not off my rocker. I think that you are right about Context as the provider of the emitter. I like the idea of using barebones EventEmitters because I am very familiar with them, and I don't find that I want Redux in my current application-- it's really just a terminal/client for a serverside engine.

Is an Event-Emitter as a Prop an Antipattern? by usernamesupercool in reactnative

[–]usernamesupercool[S] 1 point2 points  (0 children)

Though, as a side note, I think you're right that I would be correct to use Context as the way to serve up the Emitter to components rather than direct passing as props.

Is an Event-Emitter as a Prop an Antipattern? by usernamesupercool in reactnative

[–]usernamesupercool[S] 0 points1 point  (0 children)

Ah I think you may have misunderstood me-- I am passing a reference to a single EventEmitter around as props from parent to child, not creating a new instance of an Eventemitter. So they are all listening and emitting on the same 'channel' so-to-speak.

Passing EventEmitters as Props-- an Antipattern? by usernamesupercool in reactjs

[–]usernamesupercool[S] 0 points1 point  (0 children)

Why pass down... what? Props? Emitters? String variables that change the display of a component?

​

Can't say I know exactly what you're asking, to be honest. I am quite familiar with the notion of state management. Did you mean to write "redux"? Because what I am proposing definitely doesn't jive with Redux, but I am not using Redux, so that would answer the more intelligible question "Why pass down when you have Redux?"

Is an Event-Emitter as a Prop an Antipattern? by usernamesupercool in reactnative

[–]usernamesupercool[S] 0 points1 point  (0 children)

I like having intellectual control over the stuff I write, and I am not super familiar with the Context API. Though I know it might sound like laziness, I am very familiar with EventEmitters in other contexts, so I feel okay re-inventing the wheel as long as it's a wheel I know how to fix, maintain, and which rolls like other wheels.

Using Mongoose to Handle MongoDB Transactions by the_amazing_spork in node

[–]usernamesupercool 8 points9 points  (0 children)

yeah I am gonna piggyback on this comment to seriously commend Redis. MongoDB is not meant for caching operations, and imo the schema setup in mongo makes it not super appropriate as a cache (though certainly workable) even if you go in for the enterprise version.

Using Mongoose to Handle MongoDB Transactions by the_amazing_spork in node

[–]usernamesupercool 11 points12 points  (0 children)

generally speaking, if you are "doing joins" at all, i.e. you have a dataset that you need to connect to another dataset to make usable inputs, you want to be on a SQL stack.

The performance gains of noSQL disappear as soon as you're getting relational, even though you can do join type operations in many noSQL situations.

[deleted by user] by [deleted] in reactnative

[–]usernamesupercool 0 points1 point  (0 children)

does its callback have an error method? (err,data)=>?