Complexity of Bloc pattern using Stream and BehaviorSubject












0















I'm building a prototype usgin Flutter, Bloc Pattern and Stream. As we know, using Reactive Programming with Stream is one of the best way to deveop a well-done architecture (said by Google developers)



But I'm getting a little confused using this pattern due to the complexity of the architecture.



Let's see:



I'm programming a simple sing up form with 8 fields.



Using a StatelessWidget I did something like below:



class RegisterPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final RegisterBloc bloc = BlocProvider.of<RegisterBloc>(context);

return Scaffold(
key: _scaffoldKey,
body: new Container(
height: MediaQuery
.of(context)
.size
.height,
child: new SafeArea(
top: false,
bottom: false,
child: Form(
key: _formKey,
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: <Widget>[
nameField(bloc),
lastNameField(bloc),
emailField(bloc),
passwordField(bloc),
...

...
],
),
),
),
),
));
}

....
}


Up to that point everything is ok. Now let's see a field that I've defined:



Widget nameField(RegisterBloc bloc) {
return StreamBuilder(
stream: bloc.name,
builder: (context, snapshot) {
return TextField(
onChanged: bloc.changeName,
keyboardType: TextInputType.text,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Icon(Icons.person_outline),
hintText: 'Name',
labelText: 'Name',
errorText: snapshot.error,
),
);
},
);
}


The code above is just for one field and it is quite good. But... What about the Bloc class? Here we go:



class RegisterBloc extends BlocBase with Validators {



final _nameController = BehaviorSubject<String>();
Stream<String> get name => _nameController.stream.transform(validateName);
Function(String) get changeName => _nameController.sink.add;


submit() {
final validName = _nameController.value;
// Do something
}


@override
void dispose() {
_nameController.close();
}



}


Here is the important thing: For just one field (name field) I have 3 properties it means that for 8 field I will have 24 properties only for handling the streaming part (imagine a screen with many more things)



So my question is:
Am I doing something wrong using this pattern? Is it ok? May be I'm implementing it wrongly.



Thanks and good coding!










share|improve this question























  • I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

    – stt106
    Nov 20 '18 at 9:06











  • Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

    – Jordan Davies
    Nov 21 '18 at 12:10











  • That's still fine. Once you add state and event and validator everything gets even more complex :)

    – stuckedoverflow
    Feb 6 at 11:19
















0















I'm building a prototype usgin Flutter, Bloc Pattern and Stream. As we know, using Reactive Programming with Stream is one of the best way to deveop a well-done architecture (said by Google developers)



But I'm getting a little confused using this pattern due to the complexity of the architecture.



Let's see:



I'm programming a simple sing up form with 8 fields.



Using a StatelessWidget I did something like below:



class RegisterPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final RegisterBloc bloc = BlocProvider.of<RegisterBloc>(context);

return Scaffold(
key: _scaffoldKey,
body: new Container(
height: MediaQuery
.of(context)
.size
.height,
child: new SafeArea(
top: false,
bottom: false,
child: Form(
key: _formKey,
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: <Widget>[
nameField(bloc),
lastNameField(bloc),
emailField(bloc),
passwordField(bloc),
...

...
],
),
),
),
),
));
}

....
}


Up to that point everything is ok. Now let's see a field that I've defined:



Widget nameField(RegisterBloc bloc) {
return StreamBuilder(
stream: bloc.name,
builder: (context, snapshot) {
return TextField(
onChanged: bloc.changeName,
keyboardType: TextInputType.text,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Icon(Icons.person_outline),
hintText: 'Name',
labelText: 'Name',
errorText: snapshot.error,
),
);
},
);
}


The code above is just for one field and it is quite good. But... What about the Bloc class? Here we go:



class RegisterBloc extends BlocBase with Validators {



final _nameController = BehaviorSubject<String>();
Stream<String> get name => _nameController.stream.transform(validateName);
Function(String) get changeName => _nameController.sink.add;


submit() {
final validName = _nameController.value;
// Do something
}


@override
void dispose() {
_nameController.close();
}



}


Here is the important thing: For just one field (name field) I have 3 properties it means that for 8 field I will have 24 properties only for handling the streaming part (imagine a screen with many more things)



So my question is:
Am I doing something wrong using this pattern? Is it ok? May be I'm implementing it wrongly.



Thanks and good coding!










share|improve this question























  • I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

    – stt106
    Nov 20 '18 at 9:06











  • Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

    – Jordan Davies
    Nov 21 '18 at 12:10











  • That's still fine. Once you add state and event and validator everything gets even more complex :)

    – stuckedoverflow
    Feb 6 at 11:19














0












0








0


1






I'm building a prototype usgin Flutter, Bloc Pattern and Stream. As we know, using Reactive Programming with Stream is one of the best way to deveop a well-done architecture (said by Google developers)



But I'm getting a little confused using this pattern due to the complexity of the architecture.



Let's see:



I'm programming a simple sing up form with 8 fields.



Using a StatelessWidget I did something like below:



class RegisterPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final RegisterBloc bloc = BlocProvider.of<RegisterBloc>(context);

return Scaffold(
key: _scaffoldKey,
body: new Container(
height: MediaQuery
.of(context)
.size
.height,
child: new SafeArea(
top: false,
bottom: false,
child: Form(
key: _formKey,
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: <Widget>[
nameField(bloc),
lastNameField(bloc),
emailField(bloc),
passwordField(bloc),
...

...
],
),
),
),
),
));
}

....
}


Up to that point everything is ok. Now let's see a field that I've defined:



Widget nameField(RegisterBloc bloc) {
return StreamBuilder(
stream: bloc.name,
builder: (context, snapshot) {
return TextField(
onChanged: bloc.changeName,
keyboardType: TextInputType.text,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Icon(Icons.person_outline),
hintText: 'Name',
labelText: 'Name',
errorText: snapshot.error,
),
);
},
);
}


The code above is just for one field and it is quite good. But... What about the Bloc class? Here we go:



class RegisterBloc extends BlocBase with Validators {



final _nameController = BehaviorSubject<String>();
Stream<String> get name => _nameController.stream.transform(validateName);
Function(String) get changeName => _nameController.sink.add;


submit() {
final validName = _nameController.value;
// Do something
}


@override
void dispose() {
_nameController.close();
}



}


Here is the important thing: For just one field (name field) I have 3 properties it means that for 8 field I will have 24 properties only for handling the streaming part (imagine a screen with many more things)



So my question is:
Am I doing something wrong using this pattern? Is it ok? May be I'm implementing it wrongly.



Thanks and good coding!










share|improve this question














I'm building a prototype usgin Flutter, Bloc Pattern and Stream. As we know, using Reactive Programming with Stream is one of the best way to deveop a well-done architecture (said by Google developers)



But I'm getting a little confused using this pattern due to the complexity of the architecture.



Let's see:



I'm programming a simple sing up form with 8 fields.



Using a StatelessWidget I did something like below:



class RegisterPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final RegisterBloc bloc = BlocProvider.of<RegisterBloc>(context);

return Scaffold(
key: _scaffoldKey,
body: new Container(
height: MediaQuery
.of(context)
.size
.height,
child: new SafeArea(
top: false,
bottom: false,
child: Form(
key: _formKey,
child: SingleChildScrollView(
padding: const EdgeInsets.symmetric(horizontal: 16.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: <Widget>[
nameField(bloc),
lastNameField(bloc),
emailField(bloc),
passwordField(bloc),
...

...
],
),
),
),
),
));
}

....
}


Up to that point everything is ok. Now let's see a field that I've defined:



Widget nameField(RegisterBloc bloc) {
return StreamBuilder(
stream: bloc.name,
builder: (context, snapshot) {
return TextField(
onChanged: bloc.changeName,
keyboardType: TextInputType.text,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Icon(Icons.person_outline),
hintText: 'Name',
labelText: 'Name',
errorText: snapshot.error,
),
);
},
);
}


The code above is just for one field and it is quite good. But... What about the Bloc class? Here we go:



class RegisterBloc extends BlocBase with Validators {



final _nameController = BehaviorSubject<String>();
Stream<String> get name => _nameController.stream.transform(validateName);
Function(String) get changeName => _nameController.sink.add;


submit() {
final validName = _nameController.value;
// Do something
}


@override
void dispose() {
_nameController.close();
}



}


Here is the important thing: For just one field (name field) I have 3 properties it means that for 8 field I will have 24 properties only for handling the streaming part (imagine a screen with many more things)



So my question is:
Am I doing something wrong using this pattern? Is it ok? May be I'm implementing it wrongly.



Thanks and good coding!







stream flutter reactive-programming






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 '18 at 1:26









Faustino GagnetenFaustino Gagneten

7151723




7151723













  • I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

    – stt106
    Nov 20 '18 at 9:06











  • Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

    – Jordan Davies
    Nov 21 '18 at 12:10











  • That's still fine. Once you add state and event and validator everything gets even more complex :)

    – stuckedoverflow
    Feb 6 at 11:19



















  • I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

    – stt106
    Nov 20 '18 at 9:06











  • Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

    – Jordan Davies
    Nov 21 '18 at 12:10











  • That's still fine. Once you add state and event and validator everything gets even more complex :)

    – stuckedoverflow
    Feb 6 at 11:19

















I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

– stt106
Nov 20 '18 at 9:06





I think this is ok though I am not an expert of BLOC. But having more code in BLOC is definitely better than having them in UI code.

– stt106
Nov 20 '18 at 9:06













Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

– Jordan Davies
Nov 21 '18 at 12:10





Looks good to me, but I'm very new to flutter and the bloc architecture too. You could split your register bloc into a validation bloc and submit bloc maybe?

– Jordan Davies
Nov 21 '18 at 12:10













That's still fine. Once you add state and event and validator everything gets even more complex :)

– stuckedoverflow
Feb 6 at 11:19





That's still fine. Once you add state and event and validator everything gets even more complex :)

– stuckedoverflow
Feb 6 at 11:19












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384950%2fcomplexity-of-bloc-pattern-using-stream-and-behaviorsubject%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384950%2fcomplexity-of-bloc-pattern-using-stream-and-behaviorsubject%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

Tangent Lines Diagram Along Smooth Curve

Yusuf al-Mu'taman ibn Hud

Zucchini